このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
バージョンの交渉が終了した後は、
接続に使用するセキュリティの種類の交渉を行う。
これは、Security ハンドシェイクと呼ばれている。
Security ハンドシェイクは、2 つのステップで行われる。
1 つめがセキュリティの種類の交渉、
2 つめが種類によって異なる処理である。
Security ハンドシェイクは、RFB バージョンによって、
その内容が異なるため注意が必要だ。
現在定義されている RFB バージョンは 3.3, 3.7, 3.8 の 3 つ。
3.8 に対応したサーバを作る場合は、
3.3 や 3.7 にも対応しておいた方が良いため、
これらの違いも一緒に見ていこう。
では、セキュリティの種類の交渉を見ていこう。
セキュリティの種類は、1 バイトの整数として表現され、
RFB の仕様書では、以下の種類が定められている。
0: Invalid（何らかの理由で通信に失敗したことを通知）
1: None（認証なし）
2: VNC Authentication（パスワードによる VNC 認証）
5, 6, 16, 17, 18, 19: 予約済み
VNC はセキュリティの種類を拡張できるようにしているため、
実装によっては上記以外の値が使われる可能性もある。
上記の中で通信が失敗したことを示す Invalid は、
特別な使い方をするため、後で説明する。
Invalid 以外の場合は、まず、
サーバが自身のサポートする種類を送信する。
RFB 3.7 以降では、サーバがサポートする種類全てを、
配列としてクライアントに送信する。
このメッセージは可変長である。
U8 length; // types 配列の長さ（種類の数）
U8 types[]; // サーバが対応する種類の配列
例えば、サーバが認証なしと VNC 認証の両方に対応する場合
0x02, 0x01, 0x02 という 3 バイトを送信することになる。
これを受取ったクライアントは、種類の中から 1 つ選び、
その種類を単独の値として送り返す。
サーバが 1 種類しか送信しなかった場合でも、
必ず 1 つの値を送り返すことになる。
U8 type; // クライアントが選択した種類
これにより、セキュリティの種類が確定する。
RFB 3.3 では、0～2 までの値のみが使われ、
サーバが上記のどれかの値を単独の値として送信する。
こちらは 32 ビット整数値として扱われる事に注意。
U32 type; // サーバのセキュリティの種類
RFB 3.3 では、クライアントに選択肢はなく、
これだけでセキュリティの種類が確定する。
さて、保留した Invalid は特殊な意味を持ち、
何かしらの原因でサーバが利用できないことを示す。
この場合は少し特殊な形式となり、サーバは
失敗の原因をクライアントに送信したあと切断する。
U8 type; // Invalid (0)
String reason; // エラーの原因を表す文字列
この String は RFB のデータ型だ。
http://mixi.jp/view_diary.pl?id=293271817&owner_id=2300658
これは RFB 3.3 でも RFB 3.7 以降でも同じである。