Software/通信プロトコル

過去にやって失敗したりうまくいったりしてことによって得た知見

データ形式

• 通信ヘッダの先頭にはプロトコル名とプロトコルバージョンを固定長で記述しろ
  • 受信開始時に先頭を何バイトか読んで、この通信は受け取っていいものかどうか、受け取る場合どういった処理系で受けるかを判断する情報をデータの通信に埋めておけ。これをちゃんとやっておかないと、後からプロトコルの拡張ができずにひどい目にあう。

• ヘッダ部分以外では固定長はやめておけ
  • 通信プロコルは基本的に「ヘッダ＋データ部」といった構成になると思う。このとき、データ部を固定長にするのはやめておいたほうがいい。へたに固定長にするとデータ量の増減に対する柔軟性がなくなる。

• ヘッダには一意な通信セッションID、送信番号を含めるべき。1ヘッダに対しデータ部の上限は長すぎないようにすべき
  • 長大なデータを送信するときは、データの合間合間に通信ヘッダが割り込める予知を残すべき。一度に大量のデータを割り込みなしで送るような仕様だと、通信中にキャンセルなどを割り込ませることができなくなる。
  • セッションIDをヘッダに付与しておけば、ヘッダ単位で通信をパイプライン化することもできる。

• データ部は Key、Type、Length、Valueで送信しろ
  • データ部には複数の値をセットすることが多いと思う。このとき、データの順番が前後してもいいように値ごとにKeyを先行させたほうが柔軟性が増す。Keyの後には値の型をあらわすType、長さを表すLengthをつけて、Valueは可変長にしておいたほうがよい。
  • Keyに特定のルールを持たせておけば、なんらかの要因でオフセットがずれた場合にKeyの検証でずれが発生していることを検出できてよい。
  • Lengthはある程度の長さにとどめておいて、最上位ビットがセットされている場合、次のKey、Type、Length、Valueで続きのデータを送るようにしたほうがよい。長い値を送るときに事前に全体の長さを算出する必要がないため、送出側でサイズの計算が不要になる。(受ける側で必要なバッファが不明になるが、受ける側は受けきれないのであればエラーを返せばいい)