2007 年 1 月 1 日 23 時 55 分

イベント駆動


このアーカイブは同期化されません。 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 サーバが提供する画面によって全く異なるため、
それを決めるのはサーバの実装者の仕事となっている。



Copyright (c) 1994-2007 Project Loafer. All rights reserved.