私は、一連のピア間でのデータ同期へのアプローチを検討し始めました。ピアは切断された方法で動作し、ローカルの変更をマージするために相互に同期できる必要があります。
ピアは、ローカルアップデートを「3方向マージ」とマージできるはずです。そのため、同期ピアでは、どのファクトがより新しいかを知る必要がありますが、厳密な順序付けがない場合は、共通ルートに基づいてファクトをマージできる必要があります。
独立したピアが変更を行う場合、「クロック」を使用して「タイムスタンプ」を付けることができます。「時計」と「タイムスタンプ」という用語を使用しますが、ウォールタイムクロックを意味しません。私は、因果関係を明確にするイベントのある種の部分的な順序付けを意味します。それはだ「の前に起こった」非循環有向グラフ（DAG）を形成するイベント間の関係。
この部分的な順序付けを行う「通常の」方法は、ベクトルクロックを使用することです。ただし、これらは非常に大きくなる可能性があります。間隔ツリークロックなどの最近の開発では、タイムスタンプのよりコンパクトなストレージが提供されます。
私がまったく明らかにしていないのは、同期プロトコルが明らかにDAGを「単純に」明示的に保存しない理由です。（それともそうですか？）
ピアは、UUIDをランダムに生成することにより（またはなどの他の手段により<peer-name> + <local-monotonically-increasing-counter>）、独立してタイムスタンプを作成できます。このタイムスタンプの順序は、そのピアにとって完全に明確です。
2つのピアが互いに同期すると、新しいタイムスタンプに同意できます。繰り返しますが、このタイムスタンプの順序は、両方のピアにとって明確です。
現在、ピア間でDAGの前に発生したイベントを渡す必要がありますが、これのストレージおよび帯域幅の要件はわずかです。時点はグラフの頂点です。そのため、1つまたは2つの着信エッジがあります（クライアント上のイベント用に1つ、クライアント間の同期用に2つ）。これは制限されており、ネットワーク内のピアの数に依存しません。
個々の時点を使用するには、これにつながる時点のグラフが必要です。しかし、私の知る限り、することができる任意のピアを知っている時点では（それはそれ自体を生成し、または他のピアとそれを生成し、またはそれと同期するときに、別のピアによってそれを言われていた）しているにも持っていましたその時点までの歴史について知る機会。おそらくこれには帰納的証拠があると思います。
DAGの保存と同期は明示的に簡単に思えますが、これは実際に使用されていますか？そうでない場合、ベクタークロックが優先されるのはなぜですか？
ノート
ピアツーピア
クライアントサーバーソリューションよりもピアツーピアソリューションの方が望ましいです。
エンドトポロジとして考えられるのは、多数のクライアントが相互に複製するはるかに小さなサーバーグループに接続することです。ただし、この特定のトポロジを必要とするソリューションではなく、この特定のトポロジをサポートする一般的なソリューションがあると便利です。