II. 論点と選好

本節では、最近の NWG/RFC や私的な会話で提起されたいくつかの問題をそれぞれ提示し、各論点について解答または方針を提案する。多くの場合、良いアイデアであっても、我々の見積もりでは別のレベルに組み込むべきであるという理由で退けている。

A. 二重パディング

BBN レポート #1822 が説明するように、Host-to-Imp インターフェースの Imp 側は、メッセージを Imp の語境界まで埋めつつメッセージ長を保持するために、1 とそれに続く 0 個以上の 0 を連結する。さらに、Imp-to-Host インターフェースの Host 側は、メッセージを Host の語境界まで埋めるために 0 でメッセージを延長する。

BBN の機構は、送信側 Host が整数個の語を送りたい場合、あるいは送信側 Host のハードウェアが部分語を送信できる場合にはうまく機能する。しかし、送信側 Host が不規則な長さのメッセージを送りたいのに、そのハードウェアが語の倍数のメッセージしか送信できない場合には、何らかの追加の規約が必要となる。

最も単純な解決策の一つは、Host-to-Imp インターフェースの Imp 側を 0 だけを付加するように変更することである。これは、末尾の 1 を Host のソフトウェアが供給しなければならないことを意味する。BBN は、ハードウェアの変更に対する無理もない強い抵抗感から、この変更を退けた。Imp プログラムに 5 命令のパッチを当てればインターフェースが供給する 1 を取り除けるという提案もあったが、これも、メッセージの終わりを知らせるには Host のハードウェアだけに依存し、Host のソフトウェアにはまったく依存しない方が安全に思えるという新たな理由で退けられた。

他に二つの解決策もある。一つは「二重パディング」であり、送信側 Host が 10* を供給し、ネットワークも 10* を供給する。受信時には、受信側 Host が末尾の 10* 10* を取り除く。もう一つの解決策はマーキングを利用することである。マーキングとは、リーダーとメッセージのテキストの間に挿入される 01 という形式の列である。マーキングの本来の意図は、送信側 Host がテキストを語境界から始められるようにリーダーを延長することであった。マーキングを使ってメッセージを拡張し、語境界で終わる*ようにすることも可能である。

二重パディングは、テキストの先頭をリーダーに接するように置くことで、マーキングを完全に置き換えられることに注意されたい。32 ビットマシンではこれが便利でマーキングは不便であるが、他の語長、特に 36 ビットマシンでは、マーキングの方が二重パディングよりはるかに便利である。

我々には強い選好はない。一つには、我々が語の断片を送信できるからである。NWG/RFC #44 で Shoshani らは、マーキングの調整は何の問題も引き起こさないと述べており、しかも彼らは 32 ビットマシンを使っている。マーキングの考え方はしばらく前から受け入れられているので、我々は二重パディングを用いず、マーキングを使ってメッセージの長さを調整することを提案する。なお、BBN が将来ハードウェアのパディングから 1 を取り除いたとしても、送信側の Host ソフトウェアに必要な変更はごくわずかである。

はるかに洗練された (そしてより高価な) 構成が W. Sutherland によって提案された。彼は、Host/Imp インターフェースがパディングやマーキングを取り除けるほど賢くあるべきであり、さらには入力時にメッセージを構文解析してもよいと提案した。

B. 再接続

非常に多くのネットワーク関係者から、プロトコルに動的再接続を含めたことについて我々は激しく非難された。それがどのようにして含まれるに至ったかを述べることは興味深いかもしれないと考えた。

しばらく接続とその用途について考察した後、我々は接続の機構が既存の Host 内プロセス間通信の形態とどう比較されるのかを疑問に思った。関心のある側面は二つあり、文献でどのような形式体系が提示されてきたかと、どのような機構が使われているかである。形式体系が興味深いのは、それが統一的な実装と簡潔な設計につながるからである。既存の機構が興味深いのは、どの問題を解決する必要があるかを示し、ときには適切な形式体系がどのようなものであり得るかを示唆するからである。特に我々は、ダイヤルイン時にコンソールをロガーに接続する機構、ジョブを作成する機構、そしてジョブ内のさまざまなプロセスにコンソールを受け渡す機構が、きわめて独特であり、オペレーティングシステム内の他のすべての構造や機構とは別個のものになりがちであることに気づいた。

文献に関しては、いくつかの変種を伴うただ一つの考え方しかないように見える。すなわち、プロセスは自らのアドレス空間の一部を共有し、協調して互いを起こすべきだというものである。セマフォとイベントチャネルは起床信号の便利な拡張であるが、意図は基本的に同じである。(イベントチャネルはおそらく接続として機能し得るが、それは本来の用途の範囲内ではないように思われる。小規模システムでは、イベントチャネルの効率と容量は反比例する。)

既存の実装に関しては、いくつかのシステムがあるプロセスを別のプロセスからファイルのように見せることを可能にしている。SRI の SDS-940 のように、そのように接続された二つのプロセスの間に主従関係を課すシステムもあれば、MAC の AI グループの PDP-6 システムのように対等な関係を提供するシステムもある。PDP-6 システムには、上位プロセスが下位プロセスを、デバイス名やファイル名から別のデバイス名やファイル名への写像で「包み込む」ことができる機能もある。コンソールはファイルとほぼ同じ意味論を持つので、下位プロセスがコンソールと通信していると信じながら、実際には別のプロセスと通信しているということは十分にあり得る。

ネットワーク接続と既存の逐次的なプロセス間接続との類似性は、ネットワーク接続がおそらくネットワークを使用するための正しい構造であるという我々の確信を裏づける。さらに、この構造は十分に整っており、十分に多くのマシンと互換性があるので、少なくとも文献で提示されている他のプロセス間通信の形態と同程度には、形式体系あるいは理論として通用する。

我々は、いかなる新しい形式体系も少なくとも次の二つの検査に合格しなければならないと考える。

1. それはどのような未解決の問題を解決するか。

2. それはすべての操作について閉じているか。

ネットワーク接続の場合、一つ目の候補は上で挙げたもの、すなわちコンソールをジョブやプロセスに接続することに関わるすべての操作である。また、テープドライブ、プリンタ、カードリーダーといった逐次デバイスのモデル化、およびそれらのバッファリング (スプーリング、シンビオント) システムのモデル化も興味深い。

二つ目の問いは閉包性に言及している。接続の形式体系をダイヤルインとログインの手続きに適用するにあたり、我々は何らかの切り替えまたは再接続を含める必要を感じた。そのきわめて穏やかな形式が SJCC の論文で提示されており、これは NWG/RFC #33 でもある。この穏やかな形式は AEN の置き換えのみを許し、しかもそれは接続確立時に限られる。しかし、ある操作が拡張された定義域上で自然な定義を持つなら、いずれその定義を拡張することが必要になるか、少なくとも望ましくなるというのはよくある経験である。そこで我々は次の拡張を検討した。

1. 他の任意の socket (別の Host にあるものも含む) への切り替え。

2. データの流れが始まった後でも行える切り替え。

これらの拡張が有用かもしれないと感じることには、先例さえある。オペレーティングシステムの一つの見方では、利用可能なすべての電話回線は、ロガーと呼ばれる稼働中のプロセスに属するとみなされる。ロガーは呼び出しに応答し、ユーザーを選別し、ジョブとプロセスを作成する。ほとんどの電話応答装置の特徴の一つは、連続した番号のブロックとロータリー応答方式を用いることで、多数の電話回線が同じ電話番号に対応できることである。実用システムの正確なモデルを追求する中で、我々はネットワークユーザーにも同等のサービスを提供できるようにしたいと考えた。すなわち、ユーザーは公示された単一の番号を呼び出すだけでロガーに接続されるべきである。こうして切り替えについて一応の論拠が成り立つ。

次に、ロガーは利用希望者に問い合わせた後、そのユーザーを新たに作成されたジョブに接続しなければならないことがわかる。ユーザーとロガーの間のデータの流れはすでに始まっているので、転送中のデータを失ったり化けさせたりしたくないなら、フロー制御を切り替えとかみ合わせなければならない。

Host 間の切り替えに関しては、ネットワーク全体に分散し、ユーザーに知られることなく接続をある socket から別の socket へ受け渡すユーティリティサービスを容易に想像できる。また、これはより高度な電話システム、電話会社の交換手の標準的な機能、そして分散型の私設システムにも似ている。

これらの考察から、我々は既知のすべてのモデルの基礎となる一種類の再接続を見いだせる可能性を調べることにした。アルゴリズムは容易には得られなかったが、それはおそらく有限状態オートマトン理論に不慣れだったためであろう。しかし最終的に、NWG/RFC #36 で提示したアルゴリズムを作り上げた。その少し後、Bill Crowther が、競合状態に対して別の手法をとる等価なアルゴリズムを作成した。

ネットワーク関係者の反応は二つのうちのどちらかであるようだ。美しく (そしておそらくそれ自体によって) 有用であるというものか、複雑で (これもおそらくそれ自体によって) 不要であるというものである。我々にとっては後者の集団の方がはるかに目立っており、我々は動的再接続が次のものにすぎないと認める守勢に立たされた。

1. 美しいだけ

2. ログインとコンソールの受け渡しに有用

根強い批判に応えて、我々はプロトコルに次の変更を加えた。ログインのために socket <O,H,O> を呼び出す代わりに、<U,H,O> と <U,H,1> という形式の socket を、それぞれロガーのコピーの入力 socket と出力 socket とする。あるいは、ユーザー ID U でジョブが開始されている場合は、これらの socket がコンソール socket となる。したがってログインのプロトコルは、<U,H,O> と <U,H,1> への接続を開始することである。ユーザー U が使用中でなければ、ロガーのコピーが応答して呼び出し元に問い合わせる。ユーザー ID U が使用中であれば、呼び出しは拒否される。この変更は最近 Barry Wessler によって提案された。(他の人々もずっと以前にこの変更を提案していたが、我々は当時それを退けた。)

ロガーは、呼び出し元が同じ仮想ネットに属すること、すなわち呼び出し元が他のどこかの Host でユーザー ID U を持つことを要求してもよいし、ユーザーがユーザー ID U に対応するパスワードを提示することを要求してもよいし、その両方を要求してもよい。誰でも任意のユーザー ID にログインできるようにすることを選ぶシステムさえあるかもしれない。

ログイン後も、AEN 0 と 1 はコンソールの AEN のままである。各システムはおそらくコンソールを受け渡す機構を持っており、それらはネットワークユーザーのための AEN 0 と 1 を扱えるように拡張されるだろう。したがってコンソールの受け渡しは socket をポートに再接続することであり、Host 内でネットワークを介さずに行われる。

NWG/RFC #46 を受け取った後の Meyer と Skinner との会話で、彼らは Meyer の方式とも上の節で述べた我々の方式とも異なるログイン方式を提案した。彼らの新しい方式は少し優れているように思われ、我々は彼らの次のノートを楽しみにしている。

ログインは「第 3 レベル」、すなわち NCP レベルより上にあるべきだということは一般に合意されている。我々は個々のログイン方式には無頓着になりつつある。どれも問題はなさそうであり、特に感心させられるものもない。いくつかを試してみることを提案する。もちろん、ローカルのログイン手続きを変更するのはある程度の負担であるが、多様なログイン手続きを扱うことが余分な困難を課すことはないと考える。というのも、テキスト列や割り込みの規約はあまりにも多種多様なので、たとえば我々のシステムでは我々の方式に、Multics では Meyer の方式に従うという追加の負担はごくわずかだからである。

再接続を初期のプロトコルで必須とすべきではないという点で我々は合意しており、後に任意かつ実験的なツールとして提供する予定である。加えて、汎用的な再接続機能はいずれ有用になり、現在は場当たり的なオペレーティングシステムの構造に統一的な枠組みを与えるであろうという予測を、記録にとどめておきたい。

C. 接続とリンクの分離

Bill Crowther (BBN) と Steve Wolfe (UCLA) はそれぞれ独立に、リンクを特定の接続に割り当てないことを提案した。代わりに、宛先 socket をメッセージのテキストの一部に含め、ブロックされていない任意のリンクでメッセージを送ることを提案している。

我々はこの問題を NWG/RFC #37 で少し論じたが、どちらの場合にもまだ論拠があると感じている。単純さ、速度、少ないコア要件が現在重視されていることからすると、リンクと接続を結びつけたままにしておく方が効率的であるように思われる。したがって、我々はこれを推奨する。

D. エラー報告

RAND の J. Heafner と E. Harslem が述べているように、起こり得るエラーを扱うことは重要である。良い方針は、NCP のデータベースの一貫性を損なういかなる入力にも備えることである。

NWG/RFC #40 で Heafner と Harslem が、NWG/RFC #46 で Meyer が示したエラーコマンドの具体的な定式化は妥当であると思われ、その採用を推奨する。ただし、いくつか意見を述べておく。

資源エラーと他の種類のエラーは区別すべきである。資源エラーは過負荷状態の検出にすぎない。過負荷状態は、望ましくないかもしれないが、明確に定義された正当なものである。他の種類のエラーは、誤ったソフトウェアやハードウェアを反映している。資源エラーはエラー機構ではなく、その問題に固有の機構で扱うべきであると我々は考える。たとえば、待機中の <RFC> を保存する余地がもうないときには <CLS> コマンドを発行すればよい。フロー制御プロトコルは、もっぱらバッファリングの過負荷を扱うために設計されている。

本当のエラーに関しては、<ERR> コマンドが受信者にとってどのような価値を持つのか確信が持てない。おそらく受信者の NCP は壊れており、エラーコマンドを浴びせることは問題を悪化させるだけかもしれない。したがって我々は、エラーの生成は任意とし、すべてのエラーをローカルで時系列ファイルに記録し、受信した <ERR> コマンドも同様に時系列ファイルに記録することを推奨する。現時点では是正措置は規定しない。

UCLA でネットワークが稼働してからの短い期間に、我々はネットワーク自体が生成するエラーはきわめて少ないと確信するようになった。BBN のスタッフが IMP プログラムをデバッグしテストするのを見てきたが、ほとんどのエラーは正しさではなくタイミングとスループットに影響するものであったようだ。したがって、ほとんどのエラーはおそらく壊れた Host やバグのある NCP から生じるであろう。

E. 状態の検査と報告

外部の NCP が何が起きていると考えているかについての情報を得られることは、デバッグの貴重な助けとなる。これを行う便利な方法は、NCP がいつでも望むときに状態を送ることを許しつつ、要求を受け取ったときには必ず送らせることである。

我々はこの機能を主としてデバッグツールとみなしているので、255 のような独立したリンクを使うことを提案する。その意図は、状態要求の処理と状態メッセージの生成が、通常の機構をできるだけ使わないようにすることである。したがって、「状態要求」と「状態通知」のコマンドの送信にはリンク 255 を使うことを提案する。形式は NWG/RFC #40 の 2 ページにある提案に従う。

Meyer の <ECO> コマンドは容易に実装でき、外部の NCP が生きているかどうかを検査するという、より基本的な機能を果たす。この文脈では 48 ビットには何の意味もないように思われるので、<ECO> コマンドの長さは可変とすることを提案する。また、(おそらく) 8 ビットの二値スイッチの価値も不明確なので、次の一対のコマンドを推奨する。

<ECO> <length> <text>

および

<ERP> <length> <text>

ここで

<length> は 8 ビットである。

<ECO> コマンドを受信すると、NCP は <ERP> コマンドでエコーを返す。

F. 拡張と実験

NWG/RFC #46 で Meyer が正しく指摘しているように、ネットワークプロトコルは階層化されたものである。これまでのところ、三つのレベルが明らかである。

1. IMP ネットワークプロトコル

2. ネットワーク制御プログラムプロトコル

3. 特殊ユーザーレベルまたはサブシステムレベルのプロトコル

この最後のレベルは、各 Host (あるいは各ユーザー) に固有のままにしておくべきである。第 1 レベルは BBN によって十分に規定されており、ここでの我々の焦点はレベル 2 にある。我々はレベル 2 をできるだけ中立かつ単純に保ちたいと考えており、特にログインプロトコルはできるだけレベル 3 に置くべきだという点に同意する。

単純さと先見性をもってしても、レベル 2 のプロトコルを変更したり、それを使って実験したりすべき場面は生じるであろう。実験と変更に備えるため、我々は通常の接続にはリンク番号 2 から 31 のみを割り当て、残りのリンク番号 32 から 255 は実験的に使用することを推奨する。状態の要求と応答にリンク 255 を使うことはすでに提案しており、これはこの機能の実験的な側面についての我々の見方と合致している。

また、255 から下向きの制御コマンドプレフィックスを実験用に使うことも推奨する。

これら二つの規約は、任意のサイトの部分集合の間で新しいプロトコルを便利に実験できるようにするのに十分であると我々は考える。したがって、メッセージのテキストの最初の 8 ビットをメッセージのデータ型コードとするという、NWG/RFC #42 における Ancona の提案を含めることには賛成しない。

G. ポートの socket への多重化

NWG/RFC #38 で Wolfe が、NWG/RFC #44 で Shoshani らが、一つの socket に複数のポートを接続できるようにすべきだと提案している。我々の図や典型的なシステムコールはすべて socket とポートの一対一対応を示してきたが、これは厳密にローカルな実装の問題である。socket はネットワーク全体にわたる名前空間を形成しており、その唯一の目的は各オペレーティングシステムに固有の独特な構造の間を仲介することである点に注意されたい。ポートへの言及は示唆にすぎず、それに対応する内部構造がなければ無視してよい。しかし、ほとんどのシステムはそのような構造を持っているので、説明には引き続きポートを用いる。

H. エコー、割り込み、コード変換

1. 割り込み

我々は、すべてのオペレーティングシステムがキーボードからの予約文字を走査し、それを割り込み信号として解釈しているものと思い込んでいた。MIT の Tom Skinner と Ed Meyer によれば、モデル 37 TTY と IBM 2741 は 200～500 ミリ秒の「ロングスペース」を生成し、これが I/O チャネルのハードウェアによって検出されて割り込みとしてオペレーティングシステムに渡される。「ロングスペース」は文字ではなく、ASCII コードを持たず、プログラムによって生成することはできない。

1 年以上前、我々はコンソール割り込みを模擬する問題を検討し、<INT> 型のコマンドは我々の知るどのシステムも正しくモデル化していないとして退けた。今回我々は立場を改め、NWG/RFC #46 で Meyer が提案したように、INTERRUPT システムコールと <INT> 制御コマンドを実装することを推奨する。

割り込み機能には守るべき二つの制約がある。第一に、割り込み文字を走査するシステムと通信する場合には、この機能を使うべきではない。第二に、コンソールに類似しない接続はおそらく割り込みを持つべきではない。各システムは自らの規約に従うことを推奨し、<INT> を受けるべきでない接続に <INT> が到着した場合、その <INT> は破棄し、任意でエラーとして返すべきである。

2. エコーとコード変換

各サイトは現在のエコー方針を継続すべきであり、コード変換は使用するプロセスが行うべきであると我々は考える。この分野の標準化はさらなる発展を待つべきである。

テーブル駆動のフロントエンド変換器という Ancona の提案は正しい方向のように思われるが、そのような技法は、ネットワーク向けの高水準言語を含むより大きな議論の一部であると我々は考える。

I. ブロードキャスト機能

Heafner と Harslem は NWG/RFC #39 でブロードキャスト機能、すなわち <TER> と <BDC> を提案している。我々はこの機能の価値を十分に理解しておらず、そのためこれには否定的である。OS/360 の経験がもっとあれば、その価値をよりよく理解できるのではないかと思う。一般に、OS/360 やそれに類するシステムを運用しているサイトは、タイムシェアリングシステムを運用しているサイトに比べて、ネットワークプロトコルに関する我々の提案に関連性を見いだしにくいというのはおそらく事実であろう。OS/360 と、ネットワークプロトコルの基礎にある概念や前提との関係について、説得力のある意見をいただければ幸いである。

J. インスタンス番号

NWG/RFC #46 で Meyer は、socket を拡張して、その socket に接続されたプロセスを識別するインスタンスコードを含めることを提案している。我々はプロセスが互いに区別できないよう慎重に取り計らってきた。そうしたのは、計算が一つのプロセスで行われるか多数のプロセスで行われるかは、形式的にも実際的にも Host 内部だけの関心事であるという信念による。したがって我々は、ジョブ内のすべてのプロセスが協調して AEN を割り当てるべきだと考える。オペレーティングシステムにジョブ内のプロセス間でコンソールを受け渡す機能があるなら、その機能は再接続プロトコルの中でさえ、現在のネットワークプロトコルとうまくかみ合う。しかしインスタンス番号はそのような手続きを妨げる。

この問題は socket と接続の基本的な考え方に関わるので、十分に議論することを提案する。現時点では、インスタンスコードのない 40 ビットの socket 番号を推奨する。

K. AEN

我々自身も含め、socket の下位 8 ビットに対する我々の名称 AEN に特に満足している者はいない。我々は socket_number を退けたが、Meyer の socket_code にも同様に不満である。socket という語はフィールド名の一部として使うべきではなく、提案を募りたい。