생과자 라우팅 테이블은 어떻게 작동합니까?

Pastry Distributed Hash Table을 구현하려고하는데 몇 가지 사항이 이해를 피하고 있습니다. 누군가가 명확히 할 수 있기를 바랐습니다.

면책 조항 : 저는 컴퓨터 과학 학생이 아닙니다. 나는 내 인생에서 정확히 두 개의 컴퓨터 과학 과정을 밟았으며 원격으로 복잡한 것을 다루지 않았습니다. 나는 수년간 소프트웨어를 사용해 왔기 때문에 아이디어를 내 머리에 감쌀 수 있다면 구현 작업에 달려 있다고 생각합니다. 그래서 나는 명백한 것을 놓치고있을 수 있습니다.

필자는 저자들이 발표 한 논문을 읽었으며 [1] 좋은 진전을 보였지만 라우팅 테이블이 작동하는 방식에 대한 한 가지 특별한 점에 계속 매달리고 있습니다.

이 논문은

노드의 라우팅 테이블, ,로 구성되어 있는 행 항목 각각. 행의 엔트리 라우팅 테이블의 각각은 그 노드 아이디 공유 본 노드의 노드 아이디를 인터넷에 처음 N 자리수하지만 그 노드를 참조 번째 자리가 하나 갖는 보다 가능한 값 다른 은 본 노드의 ID의 제 자리. $R$ $\lceil \log_{2^b} N\rceil$ $2^b - 1$ $2^b - 1$ $n$ $n + 1$ $2^b - 1$ $n + 1$

$b$ 애플리케이션 특정 변수, 보통 약자 $4$ . 간단히하기 위해 사용합시다 $b=4$ . 위의 내용은

노드의 라우팅 테이블, ,로 구성되어 와 행 항목 각. 행에있는 엔트리 라우팅 테이블들의 각각은 그 노드 아이디 RST Fi를 지분 현재 노드의 노드 아이디를 숫자이지만 그 N 노드 참조 번째 자리가 하나 갖는 수있는 값 이외의 현재 노드의 ID에서 번째 숫자입니다. $R$ $\lceil \log_{16} N\rceil$ $15$ $15$ $n$ $n + 1$ $2^b - 1$ $n + 1$

나는 그것을 많이 이해합니다. 또한 은 클러스터의 서버 수입니다. 나도 알아 $N$

내 질문은 항목이 배치 된 행이 키의 공유 길이에 따라 달라지면 왜 행 수에 임의의 한계가 보이는 것입니까? (128 비트 nodeId를 b 비트의 숫자로 나눔) 인 경우 각 nodeId에는 32 자리가 있습니다. 따라서 이 충분히 높아지면 ? 이 시나리오에 도달하려면 340,282,366,920,938,463,463,374,607,431,768,211,457 (수학이 옳다면) 서버가 필요하지만 이상한 포함처럼 보이며 상관 관계는 설명되지 않습니다. $b=4$ $N$ $\lceil\log_{16} N\rceil > 32$

또한 서버 수가 적 으면 어떻게됩니까? 서버가 16 개 미만인 경우 테이블에 하나의 행만 있습니다. 또한 어떤 상황에서도 행의 모든 항목에 해당 서버가 없습니다. 항목을 비워 두어야합니까? 서버 수가 적더라도 리프 세트에서 서버를 찾을 수 있다는 것을 알고 있지만 두 번째 행에 대해 동일한 quandary가 발생합니다. 노드 ID가있는 서버가 없으면 어떻게됩니까? n 번째 자리의 가능한 모든 순열을 채울 수 있습니까? 마지막으로 4 개의 서버가 있고 임의의 우연히 32 자리 중 20 개를 공유하는 두 개의 노드가있는 경우 해당 노드에 대해 해당 테이블의 20 행을 채워야합니다. 필링에 근접 할 수있는 것보다 훨씬 더 많은 행이 있습니까?

여기에 내가 생각해 낸 방법이 있습니다.

접두사와 정확히 일치하는 노드가 없으면 항목은 null 값으로 설정됩니다.
nodeId의 공유 길이와 일치하기에 충분한 행이 존재할 때까지 빈 행이 추가됩니다.
원하는 메시지 ID에 대해 일치하는 항목이없는 경우에만 공유 길이가 현재 nodeId보다 크거나 같고 항목이 수학적으로 현재보다 가까운 nodeId에 대한 라우팅 테이블 검색으로 폴백합니다. nodeId는 원하는 ID입니다.
# 3에서 적합한 노드를 찾을 수 없으면 이것이 목적지라고 가정하고 메시지를 전달하십시오.

이 네 가지 가정이 모두지지됩니까? 이것에 대한 정보를 찾아야 할 다른 곳이 있습니까?

페이스트리 : A. Rowstrong 및 P. Druschel (2001)의 대규모 P2P 시스템을위한 확장 가능하고 분산 된 객체 위치 및 라우팅 - 여기에서 다운로드

— 쌀
소스

프로그래밍이 거의 없다고합니다. 이 기사는 프로그래밍 (직접)을 다루지 않고 두 노드 사이의 최단 경로 네트워킹을 다루고 있습니다. 다음 질문은 어느 정도의 네트워킹 배경을 얻었습니까? 이것은 네트워크를 통한 라우팅에 관한 것입니다.

나는 실제로 프로그래밍 경험이 충분하다고 말했다. 내가 부족하다고 느끼는 것은 컴퓨터 과학 경험입니다. 어쨌든 네트워킹 경험이 없습니다. 나는 이것이 주로 네트워킹에 관한 것이라는 당신의 주장에 동의하지 않지만, 나는 당신의 생각을 듣고 싶습니다.

Pastry (및 모든 구조화 된 P2P 네트워크)에서 라우팅 테이블의 개념은 빠른 라우팅을 보장하면서 크기를 최소화하는 것입니다.

Pastry의 라우팅 알고리즘은 다음과 같습니다.

$A$ $A$

$u$

$i$ $u$ $i$ $u$

$(i + 1)^{th}$ $i$ $\{0, …, 2^{b} – 1\}$

일반적인 시나리오의 예 : u 주소가 1111이고 객체 에 식별자 4324가있는 경우 다음과 같은 결과가 발생합니다. (4의 기본이라고 가정합니다. 즉, 주소는 [1-4] [1- 4] [1-4] [1-4]). $A$

노드 는 객체 와 접두사 0을 공유합니다 . 따라서 위의 규칙 2에 따라 노드 는 노드 1XXX, 2XXX, 3XXX, 4XXX의 주소를 저장합니다. 여기서 X는 "치료 금지"값입니다. 이 노드들 중에서 가장 가까운 것은 4XXX입니다. -하자이 4XXX 그런 다음 실제로 4013. 말할 에 전달 주소 4013.로 이제 노드에서 다시 같은 일을 반복하려고 주소를 4013으로. $u$ $A$ $u$ $A$ $u$ $u _1$ $u _1$

더 간단하게하기 위해, 여기에 다시 4013으로가는 방법의 예가 있습니다. 은 먼저 4013과 4324 사이의 크기 공통 접두어를 1로 찾습니다. 따라서 41XX와 같은 값을 포함하는 1 행으로 이동합니다. 42XX, 43XX, 44XX. 에 그 (것)들의 사이에서 닫히고 43XX입니다. -이것이 4331이라면 앞으로 나아갈 것입니다. $u _1$ $A$

여기에서 최대 홉 수는 4 홉 (XXXX)입니다! 생과자 용어로 입니다. 따라서 증가함에 따라 감소 합니다. 그러나 행의 크기 는 증가합니다! -저자들은 = 4가 균형이 좋다고 말했습니다 . $log_{2^b}$ $b$ $2^b$ $b$

실제 시나리오는 일반적으로 그렇게 일반적이지 않습니다. 네트워크에 노드가 많지 않은 상황이있을 수 있습니다. 이것이 우리가 위의 C 단계를 따르는 이유입니다. 그러나,이 알고리즘을 올바르게하기 위해서는 각 노드가 가장 가까운 두 개의 노드에 연결되어 있어야합니다 (식별자 측면에서). 이것은 정렬 된 노드의 고리를 형성 할 것이다 [예 : 1-> 3-> 4-> 9-> 10-> 11-> 1]

— 에이 제드
소스

내가 요구 한 것은 아니지만 알고리즘에 대한 매우 훌륭한 개요는 어쨌든 찬성하고 받아 들여진 대답을 제공합니다. :)

— Paddy