このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
初期化メッセージの交換が終わると、
RFB はイベント駆動方式の主処理に移行する。
この段階では、クライアントが送るメッセージ順序はなく、
ユーザの操作等で何かしらのアクションが生じない限りは、
全くメッセージが送られないこともある。
クライアントがメッセージを送らない限り、
サーバが勝手にメッセージを送信する事はないため、
サーバは任意のメッセージが届くのを待ち受け、
メッセージが届いたら、その内容に応じて反応を返す事になる。
メッセージに順序がないということは、
サーバやクライアントは受け取ったメッセージを識別し、
その内容を個別に解析する必要がある。
メッセージのサイズもメッセージによって異なる。
そのため、主処理で交わされるどのメッセージの先頭にも、
メッセージの種別を識別する 1 バイトの値が付いている。
例えば、クライアントがサーバに送るメッセージには、
以下のような種類が存在する。
便宜上、これらをクライアントメッセージと呼ぶ。
0 - SetPixelFormat
1 - FixColourMapEntries
2 - SetEncodings
3 - FramebufferUpdateRequest
4 - KeyEvent
5 - PointerEvent
6 - ClientCutText
サーバは、まず 1 バイトを読み出すことで、
到着したメッセージの種類を識別し、
種類に応じてメッセージ全体を読み出すことになるのだ。
また、サーバがクライアントに送るメッセージにも、
以下のような種類が存在する。
便宜上、これらをサーバメッセージと呼ぶ。
0 - FramebufferUpdate
1 - SetColourMapEntries
2 - Bell
3 - ServerCutText
サーバがクライアントメッセージを受け取ると、
その内容に応じて、0 個以上のサーバメッセージを返信する。
どのクライアントメッセージに対して、
どのサーバメッセージが返されるかは、
ケースバイケースである。
例えばキーボードから文字を入力した場合、
KeyEvent クライアントメッセージが流れるが、
それが仮想画面のテキスト入力エリアであれば、
文字が入力されるので画面の状態が変化するかもしれない。
しかし、それ以外の場面では、
キーが無効であるというエラー音が鳴るかもしれない。
このように、どのような挙動が発生するかどうかは、
RFB サーバが提供する画面によって全く異なるため、
それを決めるのはサーバの実装者の仕事となっている。