はじめに

3 ページ。マーキングを廃止する。代わりに、すべての通常メッセージを二つのメッセージに分ける: 一つ目はリーダーのみを含み、データが二つ目 (次の) メッセージで続くことを示す。これは、送信元ホストからその IMP へ、および宛先 IMP からそのホストへ、いずれの場合も行う。こうすれば、データの先頭を探し回る必要はなくなる。この調整が済むと、さらにもう一つの単純化が可能になる。最大メッセージ長がネットワーク内の全コンピュータの語長の公倍数 (おそらく 2880*2 ビット) であれば、長いファイルの連続するメッセージを、ずらすことなくその場で落とすことができる。

4 ページ。制御メッセージは、_制御ソケット_との間で送受信すべきであり —— 制御リンク経由で送るべきではない。制御リンクという概念は、非常に大きく不要な特殊ケースを生み出す。

5 ページ。特定のネットワーク資源にソケットを恒久的に割り当てることは奨励されるべきであり、ソケット/資源の対応関係のディレクトリがネットワークのどこかで利用可能であるべきである。おそらく各サイトに紙の冊子の形で置くのがよい。

6 ページ。リンクには、接続を識別してソケット番号をすべてのメッセージに含めずに済むようにし、NCP での表の検索を単純化する以外に、ホスト間としての目的はない。しかし、同じ番号を持つリンクが 512 本もありうる*ため、リンクは表の検索にあまり役立たない。また、特定の宛先への次に使用可能なリンクを見つけるのは非常に醜い。したがって、すべての宛先についてリンクの総数を n 本 (n = 32、64、256、あるいは他の適当な数) に制限することを提案する。言い換えれば、あるリンクは一度に一つの宛先に対してのみ (実際には、接続に使うリンクを選ぶのは受信側なので、一度に一つの宛先からのみ) 使用される。この変更により、次に使用可能なリンクを選ぶのは非常に簡単になり、私としては、それだけの理由であっても価値のある変更だと思う。表の検索を単純化するという問題は、もう少し複雑である。受信側がリンクを選ぶのだから、NCP の受信部分ではリンクをそのまま表の索引として使うのは容易である。しかし、NCP の送信部分では、依然としてハッシュ表か線形探索か何かが必要である。これも次の変更で解決できる。STR に、送信側が選ぶ_疑似リンク_を追加する。このリンクは、すべての非制御メッセージにおいて、リーダー内のリンクの右隣の 8 ビットで送られる。IMP はこれらのビットを保持し、RFNM とともに返さなければならず、受信側は RET と INR においてリンクの代わりに疑似リンクを使わなければならない。NCP 受信表 (リンクで索引付けされる) に疑似リンクを、NCP 送信表 (疑似リンクで索引付けされる) にリンクを格納するのに必要な余分なメモリは、連想表を維持するのに必要なオーバーヘッドより確実に少ない。

*宛先番号は 9 ビットである。

8 ページ。割り当て機構は、NCP の受信部分が使うには非常に不便に思われる。受信側は、割り当てが受信側のバッファサイズの単位で消費されることを望んでおり、可変長でありうる送信側メッセージの単位ではない。そうでなければ、受信側はメモリのコンパクション問題を抱えることになる。

9 ページ。「cease」機構を機能させるために追加された新しい不規則メッセージは、不要だと思う。送信側は、(おそらく 1 ビットのカウンタで) ALL と GVB を追跡し、すでに再開 ALL が到着した GVB 0 を無視することができる。これにより、受信側は cease が送られたかどうかを知る必要がない。

15 ページ。もし私が NCP を実装するなら、すべての ERR を NOP と同様に扱うだろう。エラー制御機構としての ERR は複雑かつ不十分である。主要な機構が未デバッグであるために生じるバグしか捉えられない複雑な機構を、誰がデバッグしたいと思うだろうか。私が提供する唯一のエラー制御機構は、受信プロセスがすべてのメッセージについて送信プロセスへ確認を送ることである。これが長すぎる間受信されなければ、送信プロセスは、そのメッセージを保存していれば再送できる。この確認は、プロセス/NCP、NCP/NCP、ホスト/IMP、IMP/IMP などの各レベルでメッセージ損失を引き起こすエラーを捉える。現在、ホスト/IMP インターフェースは特に有用なエラー制御を欠いている。チェックサムが検出するように設計されている種類のエラーについては心配しない。ドロップビットや誤ピックアップビットが問題になるようなら、より多くのインターフェースにハードウェアを追加するか、ソフトウェアチェックサムが合わない場合に受信プロセスがプロセス間確認を送らないようにすればよい。

3 ページと 6 ページのコメントは、IMP プログラムの変更を伴う。自分がもう実装しなくてよい変更を提案するのは、少しだけ後ろめたい。しかし、Crowther と Cosell はいつもどおり、悪い変更には抵抗しつつ、分別のある変更を行ってくれると信じている。9 ページのコメントは、IMP プログラムの変更を避けることを狙ったものである。

注: 本 RFC は、Luke Hollins によって 8/99 に、オンライン RFC アーカイブへの登録のために機械可読形式にされた。