今回は、前回の内容から少しだけ入り込みます。mekikuプロトコルとIPtalk互換プロトコルを、表形式で比較してみます。
なお、ここには簡易Webサーバー機能は含みません。
項目 | mekikuプロトコル | IPtalk(互換)プロトコル |
---|---|---|
ベースプロトコル | UDP/IPv4 | UDP/IPv4 |
送信方法 | 全てブロードキャスト | 一部ブロードキャスト、他はユニキャスト |
使用するポート | 6633~6644 | 6711~7839 ※IPtalkのサイトの情報に基づく |
ポートの違いの意味 | チャンネルの違い | チャンネルおよび通信種別(メイン、連絡窓など) |
テキストかバイナリか | テキスト | テキスト |
文字コード | UTF-16LE | シフトJIS |
パケット欠落への対応 | 自動再送 | 目視確認→再度入力、送信 |
定期的なパケット送信 | HB(ハートビート) | 特になし |
このように、両者は「UDP経由のテキスト形式」であること以外は、大きく異なっています。
以下に、違いの理由について記しておきます。
■ブロードキャストの採用について
(1) パケット数の削減
(2) ネットワークへの参加失敗へのフォロー
(3) 同一班の人数制限の撤廃
(1)は当然ですが、ユニキャストは送る相手先の数だけパケットを送信することになります。一方ブロードキャストなら1パケットで全員に届きます。mekikuで無線LANを使うことは早い時期から想定していたので、パケット衝突の可能性を抑制しておきたいと考えました(無線LANでは「とりあえず送信し、他と衝突したら適当な時間待ってから再度送信」するので)。
(2)はプロトコルの詳細に立ち入る部分なのですが、IPtalk(互換)プロトコルの場合は、ログインパケットやログイン応答パケットが到達しないと、そのままネットワークに加われない状況になります(実際は利用者が入れないことに気づいて再度ログインすることになります)。mekikuでは、ある程度は自動的に入れるようにしておきたいと思いました。
(3)は(1)とも関連しますが、ブロードキャストなら、同一班に何人加わってもネットワーク負荷があまり増加しません(もちろん、送信主体が増える以上は負担も増えますが)。mekikuでは班の人数を制限したくありませんでした。自分の所属サークルの学習会では9人以上集まることが多いため、実利もあります。
■通信種別に関わらず同一ポートを使用することについて
IPtalkを要約筆記の現場などで使っていて、通信種別によっては通信できない、という事象を経験しています。例えば、メインは通信できているのに連絡窓が通信できない、という状況です。
推測ですが、これはIPtalkには問題はなく、他の何か(ファイアウォールなど)の影響ではないかと考えました。つまり、ポートを通信種別で分けていると、あまり使っていないポートは「使わないから閉じてしまう」ということが起きるのではないかと。あいにくそこまで検証する技術がないので、ただの推測です。
mekikuでは、全ての通信種別で同一ポートを使用します(通信種別は、送信メッセージのヘッダで識別しています)。継続的にポートを使用し続けることになるため、変に閉じられることもないだろうと考えています。
この点については、あいにく技術的な確証がないため、何かご存知の方からご教示いただければ幸いです。
■文字コードについて
Unicodeの採用は、mekiku開発当初から考えていました。Unicodeとして現在主流であるUTF-8ではなくUTF-16LEを採用したのは、Windowsの内部文字コードなので変換が不要なことによります。
■自動再送について
無線LANに対応することを考えた時、最大の問題はパケット落ちの頻発でした。ネット上で色々と調べてみましたが、無線LANのパケット損失率は環境の影響が大きく予想不能で、下手をすれば半分のパケットが落ちうるということだけ分かりました。
パケット損失に対抗するには、何らかの形で一度送った情報を送りなおすしかありません。TCP/IPの採用も考えましたが、ユニキャストしかないことやACKパケットが生じることからパケット数が全体として増えることや、TCPの再送機構は段々と再送間隔が伸びる(遅れが増す)こと、損失の多い環境では通らない再送や通らないACKがさらに増えてしまうことを考慮して、やめました。
mekikuの自動再送は、ほとんどの通常のパケットの後ろに、最近の送信内容をつけることにより実現しています。再送するために新たにパケットを生み出すことは、避けています。幸い、入力ウインドウでキー入力をするたびに入力モニターのためにパケットを送るので、それに自動再送内容を追加することで、比較的低コストで再送できると判断しました。また、HB(ハートビート)パケットが定期的に送信されるので、それにも自動再送データを入れています。
なお、自動再送の対象は、メインウインドウの内容と連絡窓の内容だけです。他の通信は、一時落ちたとしても次で通れば問題ない内容なので、特に再送対象にはしていません。
■定期的なパケット送信について
特に表示用パソコンですが、通常は操作しないため、いつの間にかネットワークから切断されていても気づきにくい面があります。こういった「いつの間にか落ちている」トラブルを完全に避けるのは難しいと思いますが、検出するだけなら生存確認の通信を定期的に送れば十分です。
このため、mekikuでは開発の早期から、定期的に自動パケット送信を行うこととしていました。この手のものの定番の呼び名として、ハートビート(heartbeat:心拍)と名づけています。
◀(前記事)[MP01] mekikuプロトコルについて
▶(次記事)[mtype] タイピングソフトを作るには
(一覧)[2.技術情報 (tech)]