피어 집합 간의 데이터 동기화 방법을 살펴보기 시작했습니다. 피어는 연결이 끊긴 방식으로 작업 한 다음 동기화하여 로컬 변경 사항을 병합 할 수 있어야합니다.
피어는 로컬 업데이트를 "three way merge" 와 병합 할 수 있어야합니다 . 따라서 동기화 피어는 최신 정보를 알아야하지만 엄격한 순서가없는 경우 공통 루트를 기반으로 사실을 병합 할 수 있어야합니다.
독립 피어가 변경하면 "시계"를 사용하여 "타임 스탬프"할 수 있습니다. "시계"와 "타임 스탬프"라는 용어를 사용하지만 벽시계를 의미하지는 않습니다. 인과 관계를 명확하게하는 일종의 부분적인 이벤트 순서를 의미합니다. 그것은 방향성 비순환 그래프 (DAG)를 형성하는 사건들 사이 의 "이전에 일어난" 관계입니다.
이 부분 순서를 만드는 "일반적인"방법은 벡터 시계 를 사용하는 것 같습니다 . 그러나 이것들은 매우 커질 수 있습니다. 인터벌 트리 클럭 과 같은보다 최근의 개발 은 타임 스탬프를보다 컴팩트하게 저장합니다.
내가 분명하지 않은 것은 동기화 프로토콜이 DAG를 명시 적으로 "간단하게"저장하지 않는 이유입니다. (아니요?)
피어는 UUID를 임의로 생성하여 (또는와 같은 다른 방법으로 <peer-name> + <local-monotonically-increasing-counter>) 타임 스탬프를 독립적으로 만들 수 있습니다 . 이 타임 스탬프의 순서는 해당 피어에게 명확합니다.
두 명의 피어가 서로 동기화되면 새 타임 스탬프에 동의 할 수 있습니다. 다시,이 타임 스탬프의 순서는 두 피어에게 분명합니다.
이제 피어간에 DAG 전에 발생해야하는 요구 사항이 있지만 이에 대한 스토리지 및 대역폭 요구 사항은 적습니다. 시점은 그래프 꼭지점입니다. 따라서 1 또는 2 개의 수신 에지가 있습니다 (클라이언트의 이벤트에 대해 1 개, 클라이언트간에 동기화에 대해 2 개). 이는 네트워크의 피어 수에 제한이 없습니다.
개별 시점을 사용하려면이 시점으로 이어지는 시점 그래프가 필요합니다. 그러나, 멀리 볼 수있는, 할 수있는 피어 알고 시점으로는 (그것 자체를 생성하거나 다른 피어로 생성, 또는 그것으로 동기화 할 때 다른 동료가 그에게 말했다되어있다) 한 도 했다 그 시점까지 이어지는 역사에 대해 알 수있는 기회. 아마 이것에 대한 귀납적 증거가 있다고 생각합니다.
DAG를 저장하고 동기화하는 것이 명시 적으로 간단 해 보입니다. 실제로 사용됩니까? 그렇지 않다면 왜 벡터 클록이 선호됩니까?
노트
피어 투 피어
클라이언트 서버 솔루션보다 P2P 솔루션을 선호합니다.
최종 토폴로지는 그 자체로 복제되는 훨씬 더 작은 서버 그룹에 연결하는 많은 클라이언트가 될 것입니다. 그러나이 특정 토폴로지가 필요한 솔루션이 아니라이 특정 토폴로지를 지원하는 일반 솔루션을 사용하는 것이 좋습니다.