- 노드의 id값을 기반으로 거리를 계산해서, 먼 거리의 노드는 간략하게, 가까운 노드는 자세하게 라우팅 테이블에 저장하는 기법.
- 공통된 prefix의 길이를
xor로 계산하여 각각의 bucket에 저장. - 일반적으로 bucket의 크기는 16.
- 한 노드가 모든 노드의 정보를 갖고 있으면 블럭이나 트랜젝션을 브로드캐스팅 할 때 전체 노드의 갯수만큼의 업로드를 한번에 진행해야 함. 😢
- 카뎀리아 방식을 적용한다면 블럭이나 트랜젝션을 브로드캐스팅 하는 노드는 logn만큼의 업로드만 하면 됨. 😄
- 부트스트랩 노드의 정보는 하드코딩 되어(혹은 사용자가 직접 입력하여) 알고 있다.
- 부트스트랩 노드에 자신과 거리가 가까운 몇 개의 노드를 요청한다.
- 응답받은 노드에 대해 재귀적으로 보다 더 가까운 노드가 있는지 찾아본다.
- 결과적으로 얻어낸 노드들을 자신의 라우팅 테이블에 집어넣는다.
- 전송하는 노드는 자신의 라우팅 테이블의 각 bucket에서 하나씩 랜덤하게 뽑아 메세지 전달.
- 메세지를 전달받은 노드들은 다시 자신의 라우팅 테이블에서 노드들을 골라 전달.
- 메세지가 끝까지 도달할 때까지 반복.
- 분산 노드 트리의 생성, 제어를 관리하는 클래스.
- 몇 가지 테스트가 존재.
- 일반 노드와 카뎀리아 노드의 부모 클래스.
- 일반 노드와 카뎀리아 노드에서 공통적으로 사용하는 메소드가 정의됨.
- 카뎀리아 노드의 구현.
- 신규 노드는
Bootstrap을 통해 1.2의 과정을 거쳐 부트스트랩 노드에 연결. - 블럭이나 트랜젝션 등의 메세지를 브로드캐스트 할 때에는 각 bucket 내에서 임의의 노드를 하나만 선택하여 메세지를 전달.
- 메세지를 전달받은 노드는 해당 메세지를 전송한 노드의 정보를 자신의 라우팅 테이블에 추가.
- 주기적으로 자신의 라우팅 테이블의 모든 노드에
Ping을 수행.
- 모든 피어의 정보를 가지고 있는 일반적인 노드의 구현체.
- 카뎀리아 구현에서의 라우팅 테이블에서 사용되는 구성 요소.
- 갖고 있는 노드의 수가 최대가 아닐 때에는 노드를 바로 추가하지만, 그렇지 않을 때에는 가장 오래 전에 사용한 노드가 살아있는지 검사한 후 살아있다면 추가하지 않고 죽어있다면 제거하고 추가.
- 동시에 엄청난 수의 노드가 죽어버리면 네트워크가 분리됨.
- 매우 극단적 상황으로 거의 일어나지 않음
- 최초의 부트스트랩 단계에서 가까운 노드들을 가져오는 과정이 즉시 일어나지 않기 때문에 블럭을 생성했어도 네트워크와 연결되어 있지 않은 상태일 가능성이 있음.
- 최초의 부트스트랩 단계를 성공적으로 완료했더라도 모든 노드들의 정보를 갖고 있지 않기 때문에 메세지 전송이 모든 노드에게 이뤄지지 않음.
- 핑을 브로드캐스팅 할 때 업로드는 logn번만 하지만, 퐁을 다운로드 할 때는 n개의 노드 전체로부터 받음.
- 단방향 핑?