RFC143 日本語訳

Network Working Group                                         W. Naylor
Request for Comments #143                                     J. Wong
NIC #6728                                                     C. Kline
Categories:  D.1, D.3                                         J. Postel
Obsoletes:  None                                              UCLA - NMC
Updates:  123, 145                                            3 May 1971

コメント#143J.ウォンNIC#6728のC.クラインカテゴリを求めるワーキンググループW.ネーラーの要求をネットワークでつないでください: D.1、ポステルが時代遅れにするD.3J.: UCLAのいずれ--でないNMCアップデート: 123 145 1971年5月3日

                    Regarding Proferred Official ICP

Proferredの公式のICPに関して

We should like to comment on a race condition discovered in the ICP as
proposed in NWG/RFC #123.  The problem arises when the server attempts
to initiate a second connection to the user's receive socket and the
first connection is not yet closed.  Using a similar notation to that of
NWG/RFC #123 the following table illustrates the sequence of events in
the proferred and proposed ICP.  The last two columns indicate which
actions must be completed before the current action may be initiated.
User and Server are third level programs, and UNCP and SNCP are the
users NCP and Servers NCP respectively.  Allocates have not been
included since they add nothing to the argument.

NWG/RFC#123で提案されるようにICPで発見された競合条件を批評したいと思います。 2番目の接続をユーザのものに開始するサーバ試みがソケットを受けて、最初の接続がまだ閉店していないとき、問題は起こります。 NWG/RFC#123のものへの同様の記法を以下がテーブルの上に置く使用すると、proferredされて提案されたICPのイベントの系列は例証します。 最後の2つのコラムが、現在の動きが開始されるかもしれない前にどの操作を完了しなければならないかを示します。 SNCPはそれぞれユーザとServerは第3レベルのプログラムと、UNCPであり、ユーザNCPとServers NCPです。 割り当て、彼らが議論に何も加えないので、含められないでください。

                                               Required Predecessors
                                               ---------------------
Reference #   Action              Initiator   "Proferred"   Proposed
-----------   ------              ---------   -----------   --------
    1         Listen(L,32)        Server           --          --

必要な前任者--------------------- 行動を起こさせるもの"Proferred"という参照#は提案しました。----------- ------ --------- ----------- -------- 1 サーバを聴いてください(L、32)--、--

    2         Init(U,L,32)        User             --          --

2イニット(U、L、32)ユーザ--、--

    3         RTS(U,L,'l')        UNCP             2           2

3RTS(U、L、'l')のUNCP2 2

    4         STR(L,U,32)         SNCP          1 and 3     1 and 3

4 STR(L、U、32)SNCP1と3 1と3

    5         Send(L,S)           Server           4           4

5は(L、S)にサーバ4 4を送ります。

    6         SEND('l',S)         SNCP             5           5

6はSNCP5 5を送ります('l'、S)。

    7         RECEIVE('l',S)      UNCP             6           6

7はUNCP6 6を受けます('l'、S)。

    8         Receive(U,S)        User             7           7

8はユーザ7 7を受けます(U、S)。

    9         Close(L)            Server           5           5

9 近い(L)サーバ5 5

   10         CLS(L,U)            SNCP          9 and 7     9 and 7

10CLS(L、U)のSNCP9と7 9と7

   11         Close(U)            User             8        not used

8が使用しなかった11の近い(U)ユーザ

   12         CLS(U,L)            UNCP            11          10

12CLS(U、L)のUNCP11 10

                                                                [Page 1]

NWG                 Regarding Proferred Official ICP             RFC 143

[1ページ] Proferredの公式のICP RFC143に関するNWG

                                               Required Predecessors
                                               ---------------------
Reference #   Action              Initiator   "Proferred"   Proposed
-----------   ------              ---------   -----------   --------

必要な前任者--------------------- 行動を起こさせるもの"Proferred"という参照#は提案しました。----------- ------ --------- ----------- --------

   13         Init(S,U+1,B )      Server           9           9
                          u

13 イニット(S、U+1、B)サーバ9 9u

   14         RTS(S,U+1,'l' )     SNCP            13          13
                           2

14RTS(S、U+1、'l')のSNCP13 13 2

   15         Init(S+1,U,B )      Server          13        14 and 18
                          s

15 サーバ13 14と18秒間のイニット(S+1、U、B)

   16         STR(S+1,U,B )       SNCP            15          15
                         s

16 15秒間のSTR(S+1、U、B)SNCP15

   17         Init(U+1,S,B )      User            11          12
                          u

17 イニット(U+1、S、B)ユーザ11 12u

   18         STR(U+1,S,B )       UNCP            17          17
                         u

18 STR(U+1、S、B)UNCP17 17u

   19         Init(U,S+1,B )      User            17          17
                          s

19 17秒間のイニット(U、S+1、B)ユーザ17

   20         RTS(U,S+1,'l' )     UNCP            19          19
                           3

20RTS(U、S+1、'l')のUNCP19 19 3

Note that in the Proferred Order column, 16 can occur before 12 in which
case UNCP would find socket U in use and probably return a CLS (U,S+1).
The Server would probably then assume the User was finished with the
conversation.

Proferred Orderコラムでは、16がケースUNCPがソケットUが使用中であることがわかる12時以前起こることができることに注意してください、そして、たぶん、CLS(U、S+1)を返してください。 そして、Serverは、たぶんUserが会話で終わったと仮定するでしょう。

The above problem is resolved by eliminating the Close from one side and
causing that side to wait for the CLS from the other side before doing
an Init.  We propose that eliminating the user's Close (U) is the best
solution.  (The user NCP must of course return a CLS in response to the
CLS sent by the server NCP).

Initをする前に、半面からCloseを排除して、その側がCLSを待つことを引き起こすことによって、上の問題は反対側から解決されています。 私たちは、ユーザのClose(U)を排除するのが、最も良いソリューションであるよう提案します。 (ユーザNCPはもちろんサーバNCPによって送られたCLSに対応してCLSを返さなければなりません。)

The Server's Close (L) leads more quickly to the reuse of socket L thus
the serving of another user.

その結果Close(L)が、よりはやくソケットLの再利用に導くServerは別のユーザの給仕です。

                                                                [Page 2]

NWG                 Regarding Proferred Official ICP             RFC 143

[2ページ] Proferredの公式のICP RFC143に関するNWG

To clarify the above discussion which may seem confusing at first
glance, let us demonstrate the problem in the language of RFC #123.

一見したところでは紛らわしく見えるかもしれない上の議論をはっきりさせるために、RFC#123の言葉を借りて言えば問題を示しましょう。

          Server                              User
          ------                              ----
     (S1) Listen(L,32)                   (U1) Init(U,L,32)

サーバーのユーザ------ ---- (S1) (U1)イニットを聴いてください(L、32)。(U、L、32)

     (S2) [Wait for match]               (U2)

(S2)[マッチを待っています](U2)

     (S3) Send(L,S)                      (U3) Receive(U,S)

(S3)が(L、S)(U3)を送る、受信(U、S)

     (S4) Close(L)                       (U4) Close(U)

(S4) (L) 近くに、(U4)は閉じます。(U)

     (S5) Init(S,U+1,B )                 (U5) Init(U+1,S,B )
                      u                                   u

(S5)イニット(S、U+1、B)(U5)イニット(U+1、S、B)u u

     (S6) Init(S+1,U,B )                 (U6) Init(U,S+1,B )
                      s                                   s

(S6)イニット(S+1、U、B)(U6)イニット(U、S+1、B)s s

Notice that since server and user are independent (probably in different
hosts), server could execute (S6) before user executes (U4) and could
receive an error back from user's NCP that socket U is busy.  Similarly,
user could execute (U6) before server executes (S4) and could receive an
error back from his own NCP that socket U is not yet closed (assuming an
implementation where sockets are kept busy until a CLS match).

サーバとユーザが独立していて(たぶん異なったホストの)、サーバがユーザが(U4)を実行する前に(S6)を実行できて、誤りを受けるかもしれないので、ユーザのものから忙しい状態でソケットUがそうであるNCPを支持する通知。 同様に、ユーザは、サーバが(S4)を実行する前に(U6)を実行できて、ソケットUが彼自身のNCPからの誤りですが、受信できましたが、閉じました(CLSが合うまでソケットが忙しく保たれるところで実装を仮定します)。

Various modifications could be made to ICP to solve this problem.  We
propose the following ICP:

この問題を解決するのを様々な変更をICPにすることができました。 私たちは以下のICPを提案します:

                                                                [Page 3]

NWG                 Regarding Proferred Official ICP             RFC 143

[3ページ] Proferredの公式のICP RFC143に関するNWG

          Server                              User
          ------                              ----
          Listen(L,32)                        Init(U,L,32)

サーバーのユーザ------ ---- イニットを聴いてください(L、32)。(U、L、32)

          [Wait for match]

[マッチのための待ち]

          Send(L,S)                           Receive(U,S)

発信、(L、S)は受信されます。(U、S)

          Close(L)                            [Wait for CLS]

(L)を閉じてください。[CLSのための待ち]

          Init(S,U+1,B )                      Init(U+1,S,B )
                      u                                   u

イニット(S、U+1、B)イニット(U+1、S、B)u u

          [Wait for match]                    Init(U,S+1,B )
                                                          s

[マッチを待っています] イニット(U、S+1、B)s

          Init(S+1,U,B )
                      s

イニット(S+1、U、B)s

This ICP assumes the following:

このICPは以下を仮定します:

1.  The user can inquire or is notified of the fact that one of his
    connections has been closed.

1. ユーザは、問い合わせることができるか、または彼の接続のひとりが閉じられたという事実について通知されます。

2.  The server can inquire or is notified that a connection for which
    he has done an Init (or Listen) is now open.

2. サーバは、問い合わせることができるか、または彼がInit(または、Listen)をした接続が現在オープンであるように通知されます。

Both of the above seem basic to any NCP - user interface.

上記の両方がどんなNCPにも基本的に見えます--ユーザーインタフェース。

This race condition problem would not exist had the dynamic reconnection
features of RFC #36 been included in the NCP protocol and had dynamic
reconnection been used in this ICP.

この競合条件問題は、RFC#36のダイナミックな再接続機能がNCPプロトコルに含まれていたなら存在しないで、このICPで使用されるダイナミックな再接続を持っていました。

       [ This RFC was put into machine readable form for entry ]
        [ into the online RFC archives by Walter Pienciak 1/98 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ウォルターPienciak1/98によるオンラインRFCアーカイブへの]

                                                                [Page 4]

[4ページ]