I 概要
ネットワークプロトコルは三つの機能を提供する。
-
接続確立
-
フロー制御
-
再接続
再接続が接続確立とは別に扱われるのは、一つには再接続が複雑であるためであり、もう一つには、これらの概念を統合された形で提示するだけの経験をプロトコルについて私が十分に持っていないためである。
接続確立
接続確立は、NWG/RFC #33 の場合と本質的に同じように動作する。大きな変更点は、より一般的な形の切り替えが接続確立とは独立に提供されるようになったことであり、そのため接続確立は切り替え手順を含まないことによって簡素化されている。
接続確立のおおよそのシナリオは次のとおりである。
-
ホスト A のプロセス PA がソケット SA を確保し、ソケット SB との接続を要求する。プロセス PA はこれをシステムコールによって行う。
-
上記と並行して、ホスト B のプロセス PB がソケット SB を確保し、ソケット SA との接続を要求する。
-
プロセス PA の要求に応じて、ホスト A のネットワーク制御プログラム (NCPA と呼ぶ) が接続要求 (RFC) コマンドをホスト B へ送る。ホスト B の NCPB は同様のコマンドをホスト A へ送る。順序は規定されていない。NCPB は、NCPA からコマンドを受け取る前でも後でも、NCPA へコマンドを送ってよい。
-
NCPA と NCPB は、それぞれが RFC コマンドを受信し、かつ自分が送信したものに対する RFNM を受信したときに、接続が確立されたことを認識する。その後、両者はそれぞれプロセス PA と PB に、接続が確立されたことを通知する。
従われる規則の一つは、SA が送信ソケットで SB が受信ソケットであるか、その逆であるかのいずれかであるということである。この条件は「SA と SB は送受信ペアでなければならない」と述べられることがある。
- 送信側プロセスはこれで送信できる。
フロー制御
送信側プロセスが受信側プロセスを溢れさせないようにするには、受信側プロセスがフローを停止できる必要がある(*)。フロー制御はネットワークの RFNM 処理に統合されている。受信側ホストが特定のリンク上でのフローを抑止したいときは、そのホストが自分の IMP に特別なメッセージを送り、それによってそのリンク上の次の RFNM が変更される。送信側ホストはこのメッセージを RFNM として、かつ送信停止の要求として解釈する。確認の制御コマンドが返される。
受信側ホストが再び受信する準備ができると、送信側ホストに送信を再開するよう告げるコマンド (RSM) を送る。
再接続
非常に多くの理由から、接続の一方 (または両方) の端をあるソケットから別のソケットへ切り替えられることが望ましい。切り替え処理に課される制限に応じて、その実装は容易なことも困難なこともある。最大限の一般性を達成するため、ここでは動的な再接続の方式を提示する。これは、フローが開始された後でも再接続を行えることを意味する。大多数の場合には、この方式は必要以上に高コストであることが判明するかもしれない。しかし、次の利点が主張される。
-
接続を切り替えるあらゆる形態が提供される。
-
再接続は、接続上で送られるメッセージの処理にオーバーヘッドをもたらさない。すなわち、コストのすべてはプロトコルの処理において負担される。
*BB&N は、無制限のバッファリングを提供すべきだと主張する。それが適切な戦略である可能性もある。しかし、それは私の考え方にはなじまないものであり、私は各接続の受信側端において小さなバッファしか提供されないという前提に基づいてプロトコル設計を行ってきた。