Kademlia iterativeFindNode 작업 저장소가 k-buckets에 연락처를 찾았습니까?

Question

XLattice에있는 Kademlia 사양에 따라 iterativeFindNode 작업의 정확한 작동과 그것이 버킷의 부트 스트랩 및 리프레시에 어떻게 유용할까요? 이 문서의 내용 :

이 프로세스가 끝나면 노드에는 k 개의 활성 연락처 집합 (RPC가 FIND_VALUE 인 경우)이 데이터 값을 찾았을 수 있습니다. 세 쌍 중 하나 또는 값이 이면 호출자에게 반환됩니다. (§4.5, 노드 찾아보기)

발견 된 노드는 호출자에게 반환되지만 사양은 반환 된 값과 함께 수행 할 작업을 지정하지 않습니다. 어떤 노드 조회가 tRefresh (기본 Kademlia의 시간)에 대한 특정 버킷의 범위에서 수행되지 않았다면

이 노드가 그 범위의 난수를 선택하고, 재생을 수행 특히 리프레시 및 스트랩의 문맥 그 번호를 키로 사용하는 반복적 인 FindNode. 다음과 같이 (§4.6, 새로 고침)

노드는 네트워크에 연결 : [...]는 N [노드 ID]에 대한 iterativeFindNode 않습니다

가 를 실행 하는가 (§4.7을, 가입) iterativeFindNode 그 자체만으로도 k- 버킷의 컨택을 새로 고칠 수 없으며, 사양에서 컨택 버킷에 결과를 삽입하지 않아도됩니까?

참고 :

노드가 서로 통신을 수신 할 때마다

, 그것은 대응 버킷 업데이트 다음 는 동작이 지정된 K 용 버킷을 갱신 할 수있는 기본 RPC를 사용하고 그들을 통해 iterativeFindNode. (§3.4.4, 업데이트)

그러나 FIND_NODE RPC의 수신자 만 k-buckets에 삽입되며 해당 노드 (k- 연락처 목록 포함)의 응답은 무시됩니다 .

Answer 1

그러나 FIND_NODE RPC의 수신자 만 k-buckets에 삽입되며 해당 노드 (k- 연락처 목록 포함)의 응답은 무시됩니다.

저는 XLattice에 대해 말할 수 없지만, 비트 토 런트 kademlia 구현에 종사하면서 이상하게 여깁니다.

들어오는 요청은 연결할 수있는 노드 (NAT 및 방화벽 문제)로 확인되지 않지만 나가는 RPC 호출에 대한 응답은 실제로 노드에 도달 할 수 있음을 나타내는 좋은 지표입니다. 들어오는 응답은 라우팅 테이블 유지 관리에 즉시 유용해야하는 반면에 들어오는 요청은 확인해야하는 임시 연락처로만 추가 할 수 있습니다.

그러나 응답에 포함 된 트리플과 응답 자체를 구별하는 것이 중요합니다. 트리플은 검증되지 않았고 응답 자체는 해당 노드의 활성에 대한 좋은 검증입니다.

요약 : 라우팅 테이블

• 반 유용한

  들어오는 요청

• 도달이 필요
테스트 할

들어오는 응답

• 라우팅 테이블에 즉시 유용

튜플 내부에 응답하여 자신

있지만 조회 프로세스의 일부로 방문 끝낼 수에 의해

• 유용하지, 그들은 응답이 될 수 있음