IV - ユーザー制御通信プロトコル

ネットワーク内の誰に対しても listen し、適切な識別がなされたならその相手のためにプロセスを作成することに同意するプロセスが存在しなければならない。このプロセスはロガーと呼ばれ、ネットワーク関連のユーザー制御通信 (UCC) モジュールを通じて NCP を介して対話し、そのモジュールが必要なプロトコルを実装する。1 つの場合 (死んだプロセスの接続を CLOSE すること) を除き、UCC モジュールを運用するプロセスに特別なネットワーク特権はない。

UCC プロトコルの下では、"外部" プロセスの作成を指示した "要求元" プロセスは 2 本の全二重の疑似タイプライタ接続を維持する: 1 本は外部ロガーへのもの、もう 1 本は作成されたプロセスへのものである。外部ロガーへの二重接続は、要求元プロセスをロガーに対して識別するために、またログイン後に作成されたプロセスの健全性に関する基本情報を要求元プロセスへ返すために用いられる。作成されたプロセスへの二重接続は、それへの制御通信に用いられる。

2 本の全二重接続を維持することにより、ロガーが作成されたプロセスへ通信を引き渡すときも、制御を取り戻す必要があるときも、再接続の問題を避けられる。これは、要求元プロセスが 2 組の接続の間でタイプライタ通信を切り替えることを要求するという、ささやかな代償を伴う。

通信が確立される方法はおおむね次のとおりである: 要求元プロセスはまず、socket コードが連続する 4 つの自分の socket を予約する。次にこれらの socket の 1 つを指定して UCC に "信号を送る"。UCC はその "信号" から、どのプロセスが呼び出しているか、またプロトコルによって、UCC がどの要求元 socket 対で要求元プロセスと通信すべきか、作成されたプロセスがどの要求元 socket 対を自分の通信に使うべきかを知る。これは以下でより詳しく規定される。

外部プロセスの確立と操作

各ホストの UCC は常に、ユーザー番号 = 0、インスタンスタグ = 0 の送信 socket を "signal" socket として開いたまま (活動中かつ未接続) にし、この socket への INIT を定期的に調べる。このホストでプロセスを作成したいプロセスは、まずこの socket へ INIT を発行して UCC に信号を送らなければならない。

要求元プロセスは、socket コードが連続する 4 つの空き socket を持たなければならない: <base_socket> (受信) から <base_socket+3> (送信) まで。番号の大きい送受信 socket の組は外部 UCC とのタイプライタ通信に、番号の小さい組は作成されたプロセスとのタイプライタ通信に用いられる。

"要求元" プロセスは LISTEN を 2 回呼び出して <base_socket+2> と <base_socket+3> の受信/送信対を開き、それを通じて外部 UCC と対話する。次に <base_socket> 上で UCC の "signal" socket へ "信号送出" の INIT 呼び出しを送る。UCC がこの "信号送出" INIT 呼び出しに対して行う唯一のことは、それが発信された socket 番号 <base_socket> を記録することである。UCC は、自分の "signal" socket を他の信号のために開いたまま保つよう、この要求を直ちに拒否する。
UCC の信号 socket への最初の INIT 呼び出しで期待どおりの REJECT を受け取った後、要求元プロセスは <base_socket> と <base_socket+1> に対して LISTEN を発行する。(作成されたプロセスは、要求元プロセスとの制御通信を確立するためにこれらの socket を INIT する。) 次に要求元プロセスは STATUS <base_socket+2> を呼び出してブロックする。
UCC は、要求元の <base_socket+2> と <base_socket+3> へ空きの送受信 socket 対を INIT する。要求元プロセスはこれらの socket を LISTEN しているはずである。要求元プロセスは 2 つの socket を LISTEN した後、ブロックオプション付きで STATUS <base_socket+2> を呼び出しているので、外部 UCC からの INIT が要求元プロセスに達すると、STATUS は INIT の通知を伴って戻る。要求元プロセスは呼び出しているのがその UCC であることを確認してから呼び出しを ACCEPT する。次に要求元プロセスは STATUS <base_socket+3> を呼び出し、その socket への INIT が届いたときに戻る。同様の確認と ACCEPT を行う。(要求元プロセスがどちらの socket について先に STATUS を呼ぶかは任意である。) 要求元プロセスが UCC からの両方の INIT を ACCEPT したときに双方向通信が確立する。この接続はログイン儀式中および作成されたプロセスの存続期間中維持される。要求元プロセスが限られた時間内に UCC の INIT に適切に応答しない場合、UCC は接続の試みを放棄する。
次に要求元プロセスは UCC とログイン儀式を行わなければならない。(初期プロトコルはログイン儀式を標準化するかもしれない。) ロガーが満足せず要求元を切り離したい場合は、UCC モジュールは <base_socket+2> と <base_socket+3> の両方を CLOSE する。おそらくロガーが適切なメッセージを送った後で行われる。
満足すれば、ロガーはそのユーザーのためにプロセスを作成する。UCC は要求元との直接通信を維持するが、この接続は今や作成されたプロセスに関する基本情報の報告にのみ用いられる。
作成されたプロセスの最初の仕事は、その要求元プロセスとの二重の疑似タイプライタ制御接続を確立することである。作成されたプロセスは自分の送受信 socket 対の 1 つを、要求元の <base_socket> と <base_socket+1> へ INIT する。両方の要求が ACCEPT されれば、作成されたプロセスはこの接続を経て初期メッセージを送る。その後コマンドレベルに移行し、接続を経てタイプライタコマンドメッセージが届くのを待つ。作成されたプロセスが要求元プロセスとの二重通信を確立できない場合、それは自らを破棄すべきである。UCC は要求元との自分の接続を CLOSE するか、別のプロセスを作成する手はずを整える。
作成されたプロセスがログアウトされると、UCC は NCP への特権的な入口を用いて、その死んだプロセスと他のプロセスとの間のすべての接続を CLOSE し、死んだプロセスのすべてのオープン socket を非活動化する。UCC は要求元プロセスへメッセージを送り返し、その後、自分と要求元プロセスとの間の二重接続を CLOSE する。
INTERRUPT 呼び出しは、要求元プロセスから作成されたプロセスへ、要求元の受信 socket <base_socket> を経て送られる場合、標準的な "quit" の意味を持つ。作成されたプロセスからの保留中の出力はすべて打ち切られ、それは "コマンドレベル" に入って、要求元プロセスへのタイプライタ接続を経てコマンドが届くのを待つ。中断された処理は、作成されたプロセスへ "start" コマンドを発行することで再開できる。(保留中の出力に関するこの規則は、INT NCP コマンドが実装するものより制限的であることに注意。)

本稿は MULTICS の "runoff" コマンドを用いて作成された。テキストと "runoff" 要求が混在したソースファイルを "qed" テキストエディタで作成した。次にこのファイルを "runoff" コマンドでコンパイルし、完成した写しを作り出した。本稿の最新版は次のセグメント名で MULTICS 上にオンラインで存在する

>udd>Multics>Meyer>network_protocol.runoff

(END)

      REQUESTOR                                  FOREIGN
      PROCESS                                    LOGGER
      --------------                             -------------
      a. LISTEN to sockets
      <base_socket+2> and
      <base_socket+3> to be
      connected to foreign logger.

      b. INIT <base_socket>
      to "signal" socket of
      foreign logger.
                =======================================>

                                                c. remember <base_socket>
                                                   and REJECT connection
                                                   to signal socket.

      d. LISTEN to sockets                      e. INIT a logger socket
      <base_socket> and                            pair to the requestor's
      <base_socket_1> to be                       <base_socket+2> and
      connected to the created  process.          <base_socket+3>.
                                                   /
                       <==========================/

      f. ACCEPT connection
      with sockets from
      foreign logger.

                             PERFORM LOGIN RITUAL
                                                CREATED
                                                PROCESS
                                                -------------
                                                g. INIT any socket pair
                                                   to requestor's
                                                   <base_socket> and
                                                   <base_socket+1>
                                                    /
                       <===========================/
      h. ACCEPT connection
      with sockets from created
      process.

図 4: 外部ホストにおけるプロセスの確立

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

外部プロセスの確立と操作​

外部プロセスの確立と操作