全体説明

我々の見方では、各ホストは、ユーザーのテレタイプが外部のモニタと通信できるようにするための 4 つのプログラム一式を持つ。これらのプログラムの厳密な実装は、設置環境に強く依存する。したがって、ここでの説明はすべて、設計ではなく機能的な特性を述べることを意図している。

これら 4 つのプログラムは、2 組の「雄/雌」ペアからなる。ユーザーは自分のサイトの送信ロガーを使い、適切な外部サイトの受信ロガーと通信して、ユーザーのテレタイプと外部マシンのモニタとの間に全二重リンクを確立する。これにより、ユーザーは相手マシンに事前にログインしたのと同等の状態になる。リンクが確立されると、2 つのロガーは役目を終えて退き、ユーザーは自分のマシン内の送信側と対話することになる。送信側の主な機能は、ユーザーのテレタイプからの入力を取り、ロガーが確立したリンクを通じて外部ホスト内の受信側へ送ることであり、受信側はそれをモニタへ渡す（ローカルのテレタイプからの入力のように見せる）。外部モニタからの応答は受信側に渡され、受信側がリンクを通じて送信側へ送り返し、送信側がユーザーのテレタイプに出力する。各マシンの送信側と受信側は、ネットワークユーザーごとに 1 つずつ複数のコピーとして存在するか、すべてのネットワークユーザーを処理できる単一のコピーとして存在しなければならない。ただし、ロガーは同時に 1 人のユーザーだけを処理できればよく、その作業はすぐに完了するため、他の要求を満たすために自由になる。とはいえ、すぐには満たせない要求を待ち行列に入れる何らかの方法が必要である。あまり満足のいかない代替案は、ロガーが使用中にそれを使おうとしたユーザーにビジー状態のメッセージを返すことである。（もちろん、これは、設置環境が再入可能なロガーを持つことや、ロガーの複数のコピーを持つことを排除するものではない。）

受信ロガーは、どのマシンでもユーザー 0 であり、常にソケット 0 をリッスンしているべきである。（同じことは、NCP がユーザー 0、ソケット 0 宛てのすべてのメッセージを横取りして受信ロガーに渡すことでも実現できる。しかし、ロガー自体をユーザー 0 とし、NCP が他の誰のメッセージと同じようにそのメッセージを扱うほうが、より単純で筋が通っている。）

送信ロガーが呼び出されると、空きソケットのプールから未使用のソケットの組（2N と 2N+1）を取り出し、2N+1 から目的の外部ホストのユーザー 0、ソケット 0 へ CONNECT する。これにより受信ロガーが起動し、外部テレタイプ用の空きがあれば接続を受け入れる。その後すぐにこの接続を閉じ、他の送信元からのリンクを開始できるようにする。逆に、その外部テレタイプを受け入れる余地がない場合（または他の理由で受信ロガーが接続を望まない場合）は、ソケット 0 へのリンク試行は拒否される。これにより、外部ホストにログオンできないことが送信ロガーに通知され、送信ロガーがその事実をユーザーに通知する。ただし、このクローズが実際に外部ロガーから送られたものであるという保証はない。たとえば、そのソケットの保留中の呼び出し待ち行列が過負荷であれば、NCP から送られた可能性もある。

ソケット 0 へのリンクが受け入れられた場合（受信ロガーが要求に応じられることを示す）、そのリンクを閉じた後、受信ロガーは自分のプールから利用可能なソケットの組（2M と 2M+1）を選び、2M+1 から 2N へ接続する。（2N の正体は、自分のリッスンが 2N+1 からのリンクで応答されたときに判明する。）一方、送信ロガーはソケット 2N をリッスンしており、ここでリンクを受け入れて 2N+1 から 2M へ CONNECT する。受信ロガーはこのソケットをリッスンしており、リンク試行を受け入れる。

この時点で、2 つのロガーの間に全二重接続が存在する。次に両者は送信側と受信側を起動し、これらがユーザーと外部モニタの間の他のすべての通信を処理する。（送信側と受信側はロガーの一部であってもよく、ロガーから呼び出されるものでもよい。）

ユーザーが作業を終えて自分のモニタに戻ると、リンクを閉じるのは送信側の役目である。受け手側では、NCP がこの事実を受信側に通知することが非常に望ましく、そうすれば受信側はユーザーをログオフさせ（ユーザー自身がそうしなかった場合）、そのユーザーが使用していた資源を解放できる。

上記のシナリオで述べた提案プロトコルの、より正式な概要は次のとおりである。

安定状態: 外部ホストの受信ロガーが、ユーザー 0、ソケット 0 をリッスンしている。
ローカルユーザーが送信ロガーを呼び出す。
送信ロガーが CONNECT (port, 2N+1, <foreign host#,0,0>) を呼び出す。
送信ロガーが LISTEN (port, <local host#, user#, 2N>) を呼び出す。
外部ロガーの LISTEN が応答され、ローカルのユーザー番号、ホスト、#2N+1 を告げられる。
外部ロガーが利用可能なソケット（2M と 2M+1）を探す。それらが存在し、接続を確立できるなら、受け入れて直ちにリンクを閉じる。
外部ロガーが CONNECT (port, 2M+1, <local host#, user#, 2N>) を呼び出す。
外部ロガーが LISTEN (port, <local host#, user#, 2M>) を呼び出す。
送信ロガーは 2N をリッスンしており、リンクを受け入れてから CONNECT (port, 2N+1, <foreign host#, user#,2M>) を呼び出す。
2M をリッスンしている受信ロガーが、リンクを受け入れる。
ロガーが適切なハンドラを起動する。
ユーザーが終了したら、送信側が両方のリンクを閉じる。

全二重接続を確立するこの基本的方法は、ネットワーク全体で標準とすべきである。送信側、受信側、および 2 つのロガーの実装を各設置環境がどう扱うかは、ネットワークにとって重要ではなく、マシンに強く依存する。（送信側と受信側が必要であるという事実すらマシンに依存する。ネットワークの一部のメンバーは、それらの機能を別の方法で果たせるかもしれない。）しかし、送信側と受信側（またはその同等物）の間の通信については、何らかの取り決めを確立しなければならない。