チャットメッセージはどの順序で表示する必要がありますか？
これは この質問 よりも深い質問です。
分散型システムでチャットメッセージが送信されると、複数のイベントが連続して発生します。メッセージがFacebook MessengerやSlackやその他のほとんどのメッセージングシステムなどのルーティングサーバーを介して送信される場合、次のことがこの順序で行われます。
- メッセージが生成されます（ユーザーが「送信」を押す）
- メッセージがサーバーに送信されます。
- メッセージはサーバーによって受信者に転送されます。
- メッセージは受信者に表示されます。
さらに、上記と交互に次のことが起こります。
- 送信者は、サーバーがメッセージを受信したことをサーバーから学習します。
- 送信者は、受信者がメッセージを受信したことをサーバーから学習します。
- 送信者は、受信者がメッセージを見たことをサーバーから学習します。
これらのイベントの順序には多くの不確実性があり、それらの間には数分、数時間、または数日さえある場合があります。
メッセンジャーは表示することでユーザーにいくつかのフィードバックを提供します
- 1が発生したとき（しかし7が発生しなかったとき）青いシクル
- 7が発生したときに青いチェックが付いた青い円
- 8が発生したときに白いチェックの付いた青い点
- 9が発生したときの受信者のプロフィール写真
さらに、複数のデバイスでの複数のメッセージの順序は不明確です。ベクトルクロックなどの手法を使用して、部分的な順序付けを理解できますが、完全な順序付けは不可能です。ユーザーの時計が正しく設定されていない場合、またはメッセージが送信されてもサーバーに到達するのに1時間かかる場合は、ユーザーがセルタワーのカバレッジを失ったためか、さらに困難になります。
この質問には2つの部分があります。
いつメッセージにタイムスタンプを付けますか？
- ローカルデバイスで生成された場合、ローカルクロックが正しく設定されていないため、時刻が非常に不正確になる可能性があります。
- メッセージが最初のサーバーに到達したとき。つまり、メッセージが実際に送信されてから数時間または数日後にオフになる可能性があります。
- メッセージが各受信者によって受信されたとき。つまり、デバイスごとに異なる可能性があります。
- まったくありません。つまり、メッセージのタイムスタンプがないため、メッセージが数週間前に送信されたのか、今送信されたのかがわかりにくくなるだけでなく、この問題がはるかに容易になります。
次に、メッセージを表示する順序は？
- ただし、タイムスタンプの順に決定されます。
- ベクトルクロックの順序。これにより、いくつかのことが他の前に発生することが保証されます。ベクトルクロックタイはタイムスタンプによって解決されます。
タイムスタンプでメッセージを並べ替えると、ユーザーのデバイスでタイムスタンプが生成されるか、メッセージがサーバーのどこかに滞っている場合、メッセージが数分または数週間後にチャット履歴に忍び込む可能性があります。ベクトルクロックで物事を注文すると、画面に表示される注文メッセージがタイムスタンプと一致しない場合があります。
ユーザーエクスペリエンスの観点から考えてほしい。セキュリティ、パフォーマンス、数学的な正確さなど、他にも重要な見方がありますが、現時点ではそれらの観点からのフィードバックは必要ありません。
ユーザーの健全性を維持するために、2つのことを強くお勧めします。
会話のすべての参加者に常に同じ順序でメッセージを表示します。
会話の参加者ごとに異なる方法でメッセージをフィルタリングできるような方法でメッセージをフィルタリングしようとしないでください。
そうは言っても、可能であれば、中央サーバーがメッセージを受信した順序にすることをお勧めします。必要に応じて、メッセージに送信時刻を注釈として付けることができます。
これらのルールの主な理由は、参加者が会話の流れを異なる方法で理解する意図的または偶発的な状況を防ぐためです。
真実の事実のタイムスタンプは、サーバーのUTC時間です。
問題は、クライアントデバイスが常にオンラインであるとは限らないことです。モバイルにはWiFiもネットワークもないため、リクエストはキューに入れられます。また、クライアントはデバイスの時間を調整できます。
経験上、デバイスがオフラインである間、クライアントがデバイスの時間を調整しないようにする方法はありません。しかし、これは、正確なユーザーイベントタイミングに依存するシステム（ユーザーが作業の開始と終了を報告する）に対して、私たちが思いつくことができる最高のものです。
- ユーザーがアクションを実行すると、クライアントデバイスのクロックを使用してタイムスタンプが付けられます。
- 次に、サーバーへのディスパッチが試行され、試行ごとに別の（要求）タイムスタンプ（クライアント）が追加されます。
- デバイスがオンラインであり、サーバーがそれを取得した場合、サーバーは要求と元のタイムスタンプの間の差分を計算し、サーバーUTCから差し引きます。
あなたが私に尋ねれば、ほとんどのシナリオにとって完全なやり過ぎですが、これが役に立てば幸いです。