RFC197 日本語訳

Network Working Group                        A.Shoshani, SDC
Request for Comment # 197                   E. Harslem, Rand
NIC # 7142                                      14 July 1971
Categories:  C.3, D.1
Updates:  None
Obsoletes:  None

ワーキンググループA.Shoshaniをネットワークでつないでください、そして、SDCはコメント#のために197E.Harslem、ランドNIC#7142の1971年7月14日のカテゴリを要求します: C.3、D.1アップデート: なにも以下を時代遅れにしません。 なし

         INITIAL CONNECTION PROTOCOL--REVIEWED

初期の接続プロトコル--論評します。

INTRODUCTION
------------

序論------------

     At the Network meeting preceding the SJCC '71, an
"ICP Committee" was established.  It's purpose was to get
"something" working fast with minimum modifications to the
current ICP so as to minimize complaints.  (This seems like
a good definition for almost everything!)  Consequently,
those who had objections to the current ICP were interviewed
and a compromise was reached in the form of RFC #165.  The
ICP committee didn't have a chance to think about an alter-
native because of the above mentioned constraints.  In this
note we attempted a simple version of an ICP assuming that
we can add commands to Host-Host protocol. We hope that this
will be useful in the design of the next version of the
Host-Host protocol.

SJCC71年に先行するNetworkミーティングでは、「ICP委員会」は設立されました。 目的が「何か」を苦情を最小にするために現在のICPへの最小の変更で速く働かせることであったということです。 (これはほとんどすべてのための良い定義のように見えます!) その結果、現在のICPに反論を持っていた人がインタビューされました、そして、妥協にRFC#165の形で達しました。 ICP委員会には考える機会がなかった、上記の規制のためにネイティブを変更してください。 この注意では、私たちはICPが、私たちがHost-ホストプロトコルにコマンドを追加できると仮定する簡単なバージョンを試みました。 これがHost-ホストプロトコルの次のバージョンのデザインで役に立つことを願っています。

ICP COMMANDS
------------

ICPコマンド------------

     To establish a regular connection one party can issue
an INIT (NCP sends RTS or STR commands), then the other
party can accept the request for connection by responding
with an INIT or refusing it with a CLOSE.  We think that

定期便を証明するために、1回のパーティーがINITを発行できて(NCPはRTSかSTRにコマンドを送ります)、次に、相手はINITと共に応じるか、またはCLOSEと共にそれを拒否することによって、接続を求める要求を受け入れることができます。 私たちはそれを考えます。

                                                                [Page 1]

a similar, simple mechanism is desirable for the ICP.
Furthermore, the ICP should allow for simplex as well as
duplex connections from user to server.

[1ページ] ICPに、同様の、そして、簡単なメカニズムは望ましいです。 その上、ICPは重複のユーザからサーバまでの接続と同様にシンプレクスを考慮するはずです。

     The following commands are necessary for simplex
connections:

以下のコマンドがシンプレクス接続に必要です:

     ISC - Initiate Simplex Connection

ISC--シンプレクス接続を開始してください。

     ASC - Accept Simplex Connection

ASC--シンプレクス接続を受け入れてください。

     RSC - Refuse Simplex Connection

RSC--シンプレクス接続を拒否してください。

     The notation for parameters is similar to that
of RFC #165:

パラメタのための記法はRFC#165のものと同様です:

     L - Server socket name, in one special case the
         server is "logger".

L--サーバソケット名、ある特別な場合におけるサーバは「きこり」です。

     U - User socket.

U--ユーザソケット。

     S - Socket assigned by server for the connection
         with user.

S--ユーザとの接続のためにサーバによって割り当てられたソケット。

     X - Is the byte size if U is odd and is the link
         number if U is even.

X--バイトはUが同等であるなら、Uが変であり、リンク番号であるならサイズですか?

     -                           -
     X - Is the complement of X (X is the link number
         if U is odd and byte size if U is even.

- - 補数はXのものです。X--、(XはUがリンク番号であるならUが変、そして、バイトサイズであるならリンク番号でさえあります。

     To initiate a simplex connection the user's NCP
issues:
           ISC, L, U, X

シンプレクス接続を開始するために、ユーザのNCPは以下を発行します。 ISC、L、U、X

     To refuse this connection the server's NCP issues:

この接続にサーバのNCPを拒絶するのは以下を発行します。

           RSC, L, U

RSC、L、U

                                                                [Page 2]

     To accept this connection the server's NCP issues:
                         -
           ASC, L, U, S, X

サーバのNCPが発行するこの接続を受け入れる[2ページ]: - ASC、L、U、S、X

     Similarly, for duplex connections, we have:

同様に、私たちには、重複の接続のために、以下があります。

           IDC, L, U1, X1, U2, X2

IDC、L、U1、X1、U2、X2

           RDC, L, U1, U2
                           -           -
           ADC, L, U1, S1, X1, U2, S2, X2

RDC、L、U1、U2----ADC、L、U1、S1、X1、U2、S2、X2

where (U1,U2), (S1,S2), (U1,S1) and (U2,S2) are pairs of
opposite gender.

(U1、U2)、(S1、S2)と(U1、S1)と(U2、S2)が組の反対の性であるところ。

     After the server accepts the connection(s), it (they)
goes immediately to a "connected state", and the appropriate
ALL command(s) must be sent.

サーバが接続を受け入れた後に、それ(それら)はすぐ、「関連状態」、適切にすべてのコマンドを送らなければならないなります。

ADVANTAGES
----------

利点----------

     The main advantage to this approach is that it mini-
mizes the dialog between user and server.  The server socket
L is used only as an address, not a socket to connect to,
therefore eliminating the need to establish a connection to
L, choose a byte size, send an ALL command, send and receive
data on it and CLOSE it.  Race conditions as mentioned in
RFC #143 do not arise.  Socket L is the server and should
be in a "Listening for ICP" state when an ISC or IDC is
received.  If socket L is not in that state, the serving
NCP should refuse to ICP request.  The serving NCP should
_not_ queue ICP requests.

サーバユーザとサーバソケットLの間の対話が接続するのに単にソケットではなく、アドレスとして使用されて、したがって必要性を排除しているミニmizesはそれとCLOSEにLに取引関係を築いて、バイトサイズを選んで、すべてのコマンドを送って、発信して、データを受け取ります。このアプローチの主な利点がそれである、それ、それ。 RFC#143で言及する競合条件は起こりません。 ソケットLは、サーバであり、ISCかIDCが受け取られているとき、「ICPのために聴き」状態にあるはずです。 ソケットLがその状態にないなら、給仕NCPはICP要求に拒否するべきです。 給仕NCPは_待ち行列ICP要求ではなく、_がそうするべきです。

     In the current ICP, when the user choses socket U, he
has to reserve sockets U+2 and U+3.  In the above described
approach no restrictions exist for U1 and U2 (except that
they are of opposite gender);  the same is true for S1 and
S2.

ユーザchosesソケットUであるときに、現在のICPでは、彼はソケットU+2とU+3を予約しなければなりません。 上の説明されたアプローチでは、制限は全くU1とU2のために存在していません(それらが反対の性のものであるのを除いて)。 S1とS2に、同じくらいは本当です。

     We think that duplex commands are necessary since both
connections are to be connected to the same server process.
Their separation by using two ISCs, will add complications
of correlating the two ISCs with the same process.  Also,
if two ISCs are used, the first might be accepted and the
second refused.  This leads to uncertainty on the user's
part.  This condition cannot occur with the duplex commands.

私たちは、両方の接続が同じサーバの過程に接続されることになっているので重複のコマンドが必要であると思います。 彼らの分離が2ISCsを使用して、同じ過程がある2ISCsを関連させる複雑さを加えるために望んでください。 また、2ISCsが使用されているなら、1番目を受け入れたかもしれません、そして、2番目は拒否しました。 これはユーザの部分の上の不確実性に通じます。 この状態は重複のコマンドで現れることができません。

                                                                [Page 3]

MINIMUM MODIFICATION TO CURRENT ICP
-----------------------------------

[3ページ] 現在のICPへの最小の変更-----------------------------------

     The minimum change we can think of to make the current
ICP look similar to the above is to add one NCP level com-
mand -- accept:

私たちが現在のICPを上記で同様に見えさせるように考えることができる最小の変化は1つのNCPのレベルcom- mandを加えることになっています--受け入れてください:

           ACC, L, U, S

ACC、L、U、S

     The exchange between NCPs in the notation of RFC #165
is now:
<where the original uses a script lowercase "L" we use "l">
<where the original uses subscripts we use {} so that
   A-subscript-B is printed A{B} >

RFC#165の記法によるNCPの間の交換は現在です: オリジナルがスクリプト小文字の「L」を使用する私たちが使用する<、「l、「オリジナルが私たちが使用する添字を使用する><、それで、その添字Bが印刷される、A」B>。

     Server NCP                   User NCP
     ----------                   --------

サーバNCPユーザNCP---------- --------

     Listen for connection on L   RST,U,L,l{A}

L RST、U、L、lで接続の聞こうとしてください。A

     ACC,L,U,S                    S is passed by NCP to the
                                  user and connection from
                                  U to L is closed.

ACC、L、U、S SはNCPによってユーザに渡されます、そして、UからLまでの接続は閉じられます。

     STR,S+1,U+2,B{s}             STR,U+3,S,B{u}

STR、S+1、U+2、B s STR、U+3、S、Bu

     RTS,S,U+3,l{B}               RTS,U+2,S+1,l{c}

RTS、S U+3、l B RTS U+2、S+1、lc

     Wait for connection          Wait for connection

接続のために接続Waitを待ってください。

     ALL,l{B},m{B},b{B}           ALL,l{c},m{c},b{c}

l B、すべてがb Bであるm B、l c、m c、bc

     An alternative way to the ACC command is a CLS command
with an additional parameter (32 bits long).  If parameter
is zero the request for connection by the user is refused;
if the parameter is non-zero, the request is accepted and
socket S is the value of the parameter.

ACCコマンドへの代替の道は追加パラメタ(長さ32ビットの)があるCLSコマンドです。 パラメタがゼロであるなら、ユーザによる接続を求める要求は拒否されます。 パラメタが非ゼロであるなら、要求を受け入れます、そして、ソケットSはパラメタの値です。

     All suggested changes improve the ICP dialog both from
the aesthetic and efficiency points of view.  We lean strongly,
however, to the first, more major ICP modification.

すべてが、変化が美意識と効率観点からICP対話を改良するのを示しました。 しかしながら、私たちは強く1番目、より主要なICP変更に傾きます。

                                                                [Page 4]

A COMMENT ABOUT CLS COMMAND
---------------------------

[4ページ] CLSコマンドに関するコメント---------------------------

     It seems appropriate to mention here for the purpose
of the next version of the Host-Host protocol that the
CLS command has more than one function.  We think that the
CLS command should be reserved to close connections in the
"connected state" only (i.e., "open" connections).  Two
additional commands can be used for "refusing" and "reject-
ing" requests for connections:

Host-ホストプロトコルの次のバージョンの目的のためにCLSコマンドには1つ以上の機能があるとここに言及するのは適切に思えます。 私たちは、CLSコマンドが「関連状態」(すなわち、「開いている」接続)だけで接続を終えるために控えられるべきであると思います。 接続を求める「拒否」と「廃棄物ing」要求に2つの追加コマンドを使用できます:

           REJ<mysocket><yoursocket> -- when a request
           for connection is rejected unconditionally.

REJ<mysocket><yoursocket>--接続を求める要求が無条件に拒絶されるとき。

           REF<mysocket><yoursocket><reason> -- when a
           request for connection is refused temporarily
           because the NCP could not handle it.  For
           example:  no process LISTENed to it and it
           was timed-out, or NCP tables are full in which
           case the user process may try again.  The
           reason for refusing is indicated in the
           parameter "reason".

REF<mysocket><yoursocket><理由>--NCPがそれを扱うことができなかったので接続を求める要求が一時拒否されるとき。 例えば: それとそれへの過程LISTENedが全く-外で調節されなかったか、またはユーザ・プロセスが再びどのケースを試すかもしれないかでNCPテーブルは完全です。 拒否する理由は「理由」というパラメタで示されます。

[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the   ]
[ direction of Alex McKenzie.                   12/96   ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの指示。 12/96 ]

                                                                [Page 5]

[5ページ]