VNCメカニズムがどのように機能するかを理解しようとしています。
RFBプロトコル3.8の仕様は次のように述べています。
更新プロトコルは、クライアントの要件によって決定されます。つまり、更新は、クライアントからの明示的な要求に応答してサーバーからクライアントに送信されます。これはプロトコルに適応品質を提供します。クライアントとネットワークの速度が遅いほど、更新速度も遅くなります。一般的なアプリケーションでは、フレームバッファの同じ領域への変更が順番に発生する傾向があります。遅いクライアントおよび/またはネットワークでは、フレームバッファの過渡を無視してネットワークトラフィックとクライアントの描画を減らすことができます。
これは、サーバーがFramebufferUpdate
クライアント側でのみ送信することを意味するようですFramebufferUpdateRequest
。その後、クライアントはこれらのパケットを定期的に送信する必要があります。しかし、Wiresharkを通じて分析してみるとそうではないことがわかりました。画面やポインタアクティビティがない場合、クライアントからサーバに移動するパケットは表示されません。
クライアントを含まずに画面上にいくつかの画面アクティビティを作成する場合(xclock
ディスプレイをこの値に設定して実行)、最初のメッセージはクライアントからの要求ではなくサーバーからクライアントに転送されます。
だから私の質問は次のようになりますサーバーは実際に画面アクティビティがあるたびに、クライアントが要求したときにのみ更新を送信しますか?これら2つのケースはどのくらいの頻度で更新されますか?
答え1
私はこれが古い質問であることを知っていますが、答えはRFB RFCにあります。
クライアントがFramebufferUpdateRequest
次に示すサーバーincremental
にメッセージを送信するとき報告する必要がある実際の変更があるまで。 この時点で、サーバーはFramebufferUpdate
変更された長方形のデータを含むメッセージを再送信します。
つまり、ネットワークデータを見ると(おそらくkeepalivesを除く)、クライアントからサーバーに送信された最後のパケットFramebufferUpdateRequest
がとしてマークされていることがわかりますincremental
。サーバーは送信する更新があるまで応答を送信しないため、ネットワークは静かに保たれます。
より一般的には、画面が頻繁に変更され、複数の連続したメッセージが発生し、FramebufferUpdateRequest
サーバーで単一の複合メッセージが発生する可能性があります。FramebufferUpdate