1

したがって、リアルタイムの更新/通信の定義は、あるユーザーによって行われた更新が、オブジェクトにサブスクライブしている他のユーザーに中継されるとすぐに行われるときであると考えています。

しかし、これは瞬間的ではありません (データの移動には有限の時間がかかります)。だから、それは非常に短い時間を意味すると思います。

5 秒ごとに ajax ポーリングを使用する場合、ユーザー A がユーザー B の操作を確認するのにかかる時間は、5+t1+t2 (データ (http 要求) がユーザー B の PC からサーバーに到達するのにかかる時間) です。データがサーバーからユーザー A の PC に届くまでの時間)。

t1+t2 は、図から取り出せない最小の遅延です (確かにソケットはこの時間を短縮しますが、それらの要因は依然として存在しますが、小さいものです)。したがって、ソケットの場合は t1+t2+d の遅延が発生する可能性があります。d は、サーバーがイベントが内部で発生したことに気づき、それを伝播するのにかかる時間です (CPU の能力に依存します)。

それとも、リアルタイムは私たちが日常的に使用する単なる一般的な用語ですか? これは、アプリケーションではなく、まったくの好奇心からです。リアルタイム データの確立された標準があるかどうか、ただ興味があります。

4

1 に答える 1

1

「コミュニケーションをリアルタイムにするためにdをどれだけ小さくすべきかを定義する、確立されたベンチマーク/標準はありますか?」

あなたの質問は有効です。アプリケーションは常に、固有の待ち時間によって定義されtます。コンテキストが異なれば、「リアルタイム」は に関してまったく異なる意味を持つ場合がありtます。

Web と人間のユーザーが関与するアプリケーションのコンテキストでリアルタイム イベント処理を定義するための受け入れられた "標準" は、(複数の) ユーザーが遅延を "感じる" ことなくアプリケーションと対話できるようにすることです。アプリケーションは「応答性が高い」必要があります。数値的には、これは、リクエストとレスポンスの間の全体的な待ち時間 (一般的な用語) が約 100 ミリ秒を超えてはならないことを意味する可能性があります。現実世界の出来事に対する人間の応答時間は、この程度です。非常に速い反応時間を必要とするオンライン ゲームは、10 ～ 60 ミリ秒程度の全体的な遅延 (往復) 時間で完全にプレイ可能です。

ラボや業界のマシン制御などの他のコンテキストでは、リアルタイムのイベント処理は、ミリ秒、マイクロ秒、またはそれ以上の速度でイベント処理が保証されることを意味する場合があります。これはまったく異なる状況です。

Web アプリケーションに戻ると、最新のリアルタイム Web サービスには、次の特徴の 1 つまたは複数が見られると思います。

  • ユーザー インターフェイスは非常に応答性が高く、一部は JavaScript などのローカル実行によって実現されています。ユーザー側 (ブラウザーなど) で実行されるコードとリモート Web アプリケーションとの間の最終的な通信は、非同期で実行されます (ユーザーからは隠されます)。
  • バックエンドの実装は、定期的なポーリングではなく、効率的なイベント処理技術に基づいています。
  • 接続の開閉によるレイテンシとオーバーヘッドを取り除くために、ユーザーとバックエンドの間で永続的な TCP/IP 接続が使用されます (ここで、たとえば WebSocket が活躍します)。

これがあなたの質問に一般的に答えてくれることを願っています。もっと具体的に知りたいことがあれば、気軽にコメントを書いてください。

于 2013-07-27T14:29:08.913 に答える