このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
RFB は 8 ビットのバイトストリームをベースとしているため、
InputStream と OutputStream でも構わないのだが、
そのままではバイトの読み出ししかできないため使いにくい。
データのサイズや型に対応したストリームがあれば便利だ。
RFB では、いくつものデータ型や構造体があるが、
基本型としては以下のような種類が使われている。
・U8 - 符号なし 1 バイト整数型（0 ～ 255）
・U16 - 符号なし 2 バイト整数型（0 ～ 65,535）
・U32 - 符号なし 4 バイト整数型（0 ～ 4,294,967,295）
・S8 - 符号つき 1 バイト整数型（-128 ～ 127）
・S16 - 符号つき 2 バイト整数型（-32,768 ～ 32,767）
・S32 - 符号つき 4 バイト整数型（-2,147,483,648 ～ 2,147,483,647）
C 言語ではおなじみの型である。
RFB ではこれら整数型が基本となっており、
計算機に依存する浮動小数点型は定義されていない。
多バイト長の型は、ビッグエンディアンで格納され、
符号つきの値は 2 の補数を使って表現する。
さらに、RFB には文字列型も存在する。
RFB の文字列は、Latin-1 文字集合で構成され、
表現方法としては、文字列の長さを表す U32 値の後に、
1 文字を U8 で表した値の配列が続くという可変長である。
低水準なバイトストリームからみると、
文字列というのは少し複雑な型である。
Java には文字列が基本型として存在するため、
上記文字列は基本型として扱うことにしよう。
これら基本型を Java で取り扱うためには、
対応する型に対応付けをしてやらなければならない。
文字列は String で済むのだが、整数型が面倒だ。
Java では、整数型は全て符号つきだからである。
と言うことで、以下のようにマッピングすることにしよう。
・U8 => int (ゼロ拡張）
・U16 => int (ゼロ拡張）
・U32 => long (ゼロ拡張）
・S8 => int (符号拡張）
・S16 => int (符号拡張）
・S32 => int
・(文字列) => String
整数は読み書きでよく使うであろう int とした。
こうすれば、利用側でキャストを最小限にすることができる。
上記を踏まえて考えると、以下のようなメソッドを持つ
ストリームを設計すればよさそうだ。
・int readU8();
・int readU16();
・long readU32();
・int readS8();
・int readS16();
・int readS32();
・String readString();
・void writeU8(int value);
・void writeU16(int value);
・void writeU32(long value);
・void writeS8(int value);
・void writeS16(int value);
・void writeS32(int value);
・void writeString(String value);
RFB では、上記基本型を組み合わせて構造体としたものを、
意味のある通信単位として取り扱っている。
これらの構造体はメッセージと呼ばれ、
様々なものが定義されている。
メッセージは、プロトコルの拡張によって増えていくため、
これらの読み出しまでストリームで面倒を見ると厄介だ。
なので、メッセージに関しては個別にクラスを作ってもらい、
クラスが自ら処理するように設計したほうがよさそうである。
Message インタフェースなどを定義しておき、
メッセージクラスに実装してもらえばいいのかな？
・Message readMessage(Class<? extends Message> messageClass);
・void writeMessage(Message message);
こんな感じだろうか。
となると、Message 実装クラスは、
Serializable や Externalizable のように、
クラス自身がデータを読み書きすることになるな。
interface Message {
void read(RFBInputStream in);
void write(RFBOutputStream out);
}
イメージとしてはこんな感じだろうか。
うん、ある程度の構想が練れてきた。