Summary

  • RFC 914では、Telnetの一文字が41バイトのTCP/IPパケットになる。著者らの条件では、1200ボーの回線で送るのに約0.3秒かかり、一文字ずつ送る場合の実効速度は約30ボーと見積もられた。
  • Thinwire Iは例のパケットを17バイト、IIは13バイトに縮める。IIIはネットワークとトランスポートの処理をゲートウェイに任せ、文書上の平均実効速度を約900ボーと見込んだ。速さと引き換えに、接続を取り仕切る場所が変わる。

一粒の豆を送るたびに引っ越し業者を呼ぶ。1984年の低速回線では、そんな贅沢がパケット単位で起きていた。David Farber、Gary Delp、Thomas Conteが記したのは、3000～1万ドルで手に入るパソコンを、家や職場からインターネットへつなぐ問題だ。専用の56k回線は高く、手配にも時間がかかる。1200ボーや2400ボーの電話モデムなら現実的だった。ただしTelnetの一打鍵は一バイトの文字だけで旅をしない。宛先、順序、確認などを運ぶためのTCP/IPが付き、最小でも41バイトになる。

ThinwireのRFCは、その重さを待ち時間に換算した。1200ボーで41バイトを送ると約0.3秒。文字一つにつき一包みなら、実効速度は約30ボーだという。回線だけが速度を決め、同期回線として働くという計算上の条件がある。割り込み、処理、フレーム化の負担が入れば、所要時間はさらに10～50%悪くなりうる。手元で文字を表示したり、一行をまとめて編集したりすれば耐えられる操作もある。相手側に一文字ずつ反応してほしい用途では、毎回この運賃が請求される。

Thinwire Iは、前に送ったパケットを両端で覚える。次は全文を送り直さず、どの位置から何バイト差し替えるかを知らせる。Telnetの例なら更新情報は典型的に17バイトで済み、実効速度は約70ボーという見積もりになる。仕組みは素直だが、異なる種類のパケットが交互に来ると、前回のパケットがよい下書きにならない。一冊のノートで全員の仕事を管理しようとしたら、ページをめくるたびに書式が変わるようなものだ。

そこでThinwire IIは、TCP接続ごとにひな型を用意する。ヘッダーで変わった箇所をビットで示し、繰り返される大きな数値を短い差分に替える。例の41バイトは13バイトとなり、一文字の実効速度は約95ボー。代わりにパソコンは複数のひな型を、ゲートウェイは接続表を維持する。双方の記憶が食い違えば通信が止まるため、信頼できるシリアルリンクと、定期的な完全パケットによる同期回復が要る。知らないプロトコルは圧縮せずに送る。線を細く使うには、両端が同じ過去を正確に覚えていなければならなかった。

Thinwire IIIは、荷造りの工夫から担当者の変更へ踏み出す。ゲートウェイがパソコンの代理としてTCPやUDPの接続を開き、インターネット側の処理を引き受ける。パソコンとの間には、データと制御命令を多重化した一本の信頼できるシリアル流を置く。著者らの平均実効速度の見積もりは約900ボー。数字は魅力的だが、接続の入口もゲートウェイに移る。パソコンはゲートウェイで受け付け口を事前に設けてサービスを提供できる一方、外から任意の接続が通常のホスト同様に直接届くわけではない。門番が荷物を持つと、門の形も門番が決める。

RFC Editorの記録では、この文書の現在の分類はHistoric。1984年の著者らは三案を議論のために示し、標準として宣言していない。計算も現場で測った導入実績ではない。だが、打鍵一回から設計の分岐が見える。線上のバイトを減らすのか、両端の記憶を増やすのか、ゲートウェイに仕事を任せるのか。細い電話線を通すための選択は、そのまま小さなコンピューターがネットワークの中でどこまで自分の足で立つかを決める。