メインコンテンツまでスキップ

初期接続プロトコル

具体的な Initial Connection Protocols (IPCs) について二つの点を述べたい。 第一に、NEW/RFC #66 に記述された IPC——その一般性と、その ICP の再記述。 第二に、NWG/RFC #66 と基本的に同じ論理を用いる変形 ICP の提案である。

I. NWG/RFC #66​

この IPC における唯一の技術的誤りは、図に示されているように、接続が確立される前に Server と User の双方がすべてのメッセージを送信している点であり、これは Network Document No. 1 と矛盾する。 これは以下に示す再記述において容易に修正できる。

一般性の観点から言えば、標準として採用されるいかなる ICP も、あるプロセスが logger を呼び出す場合よりも多くの状況に適用されるべきである。 すなわち、logger の動作とは無関係にユーザープロセスへ直接接続するようないくつかの Network サービスプロセスも、おそらく標準 ICP を使用できるであろう。 したがって、以下に示すように、サーバーソケットのプロセス名フィールドはパラメータとすべきであり、値ゼロは logger に対する特別な場合である。

NWG/RFC #66 の再記述（適切な箇所は同じ文言を用いる）​

  1. 接触を開始するために、使用プロセスは受信ソケット (US) を付加し、サービス提供 HOST 内のプロセス SERV のソケット #1 への接続を要求する。 （logger への ICP では SERV = 0 である。） その結果、使用側 NCP は次を送信する:
            1              4                 3          1     1
         +-----+---------------------+---------------+-----+-----+
         | RTS |          US         |      SERV     |  1  |  P  |
         +-----+---------------------+---------------+-----+-----+

リンク 1 を介して。ここで P は受信リンクである。

  1. サービス提供プロセス (SERV) はその呼び出しを拒否することを決める場合があり、その場合には接続を閉じる。 呼び出しを受け入れるならば、サービス提供プロセスは接続を完成させる（INIT システムコールを介して、すなわち STR となる）。
            1           3          1            4
         +-----+----------------+-----+--------------------+
         | STR |      SERV      |  1  |         US         |
         +-----+----------------+-----+--------------------+
  1. 接続が完成すると、ユーザープロセスはその接続に名目上の空間を割り当て、その結果 NCP は次を送信する:
            1     1            4
         +-----+-----+--------------------+
         | ALL |  P  |       SPACE        |
         +-----+-----+--------------------+

ここで SPACE はその量である。

  1. 次にサービス提供プロセスは、このユーザーに割り当てたいソケットペアを選択する。 それは接続を介して、偶数の 32 ビット数をちょうどそのまま送信する。 この偶数 32 ビット数 (SS) は、サービス提供 HOST における受信ソケットである。 このソケットと、その次に大きい番号のソケットが、使用プロセス用に予約される。

  2. その後、接続を閉じる。 サービス提供 NCP は次を送信する（ステップ 4）:

                    4
         +---------------------+
         |         SS          |
         +---------------------+

リンク P 上で。そして（ステップ 5）:

            1            3         1             4
         +-----+----------------+-----+--------------------+
         | CLS |       SERV     |  1  |         US         |
         +-----+----------------+-----+--------------------+

制御リンク上で（これは使用側 NCP によってエコーされる）。

  1. これでサーバーとユーザーの双方が、全二重接続のための遠隔ソケットペアを認識したので、複数の <STR, RTS> を交換できる。

サーバーがユーザーへ送信

            1            4                     4
         +-----+--------------------+--------------------+
         | STR |      SS + 1        |          US        |
         +-----+--------------------+--------------------+---+
         | RTS |         SS         |        SS + 1      | Q |
         +-----+--------------------+--------------------+---+

ここで Q はサーバーの受信リンクである。

ユーザーがサーバーへ送信

            1             4                    4
         +-----+--------------------+--------------------+
         | STR |       US + 1       |         SS         |
         +-----+--------------------+--------------------+---+
         | RTS |          US        |       SS + 1       | R |
         +-----+--------------------+--------------------+---+

ここで R はユーザーの受信リンクである。

その後 ALLocates を送信でき、伝送が開始される。

II. NWG/RFC #66 の一変形​

この変形はネットワークメッセージを削減し、情報転送の重複を排除する。

上記のステップ 3 と 4 は削除される。 ユーザープロセスは、サーバーのどのソケットが自分に割り当てられるかを直接通知されない。 しかしながらユーザープロセスは、上記のステップ 5 の後、SERV からの呼び出しをソケット US および US + 1 で待ち受ける。 これはいかなる偽の呼び出しも拒否できる。 SERV からの呼び出しを受け入れることにより、接続が確立される。

以下のサンプルシーケンスはこの ICP を例示する。 （記法は上記と同じである）。

  1. ユーザー --> サーバー
         1            4                    3         1     1
      +-----+--------------------+----------------+-----+-----+
      | RTS |         US         |       SERV     |  1  |  P  |
      +-----+--------------------+----------------+-----+-----+
  1. サーバー --> ユーザー

受け入れられた場合:

         1           3          1             4
      +-----+----------------+-----+---------------------+
      | STR |      SERV      |  1  |         US          |
      +-----+----------------+-----+---------------------+
      | CLS |      SERV      |  1  |         US          |
      +-----+----------------+-----+---------------------+

拒否された場合:

         1           3          1             4
      +-----+----------------+-----+---------------------+
      | CLS |      SERV      |  1  |         US          |
      +-----+----------------+-----+---------------------+

  1. 受け入れられた場合、ユーザーは US および US + 1 を待ち受ける。

  2. サーバー --> ユーザー

         1             4                     4
      +-----+--------------------+---------------------+
      | STR |       SS + 1       |          US         |
      +-----+--------------------+---------------------+---+
      | RTS |         SS         |        US + 1       | Q |
      +-----+--------------------+---------------------+---+
  1. ユーザーが呼び出しを受け入れる。したがって:

ユーザー --> Sender

         1              4                     4
      +-----+---------------------+--------------------+
      | STR |        US + 1       |        SS + 1      |
      +-----+---------------------+--------------------+---+
      | RTS |        US + 1       |          SS        | R |
      +-----+---------------------+--------------------+---+

そして接続が確立される。

これはネットワークメッセージの数を二つ削減し、サーバーのソケットに関する情報を RTS と STR を介して一度だけ渡す。