RFC215 日本語訳

Network Working Group                                      A. McKenzie
Request for Comments: 215                                          BBN
NIC #7545                                               30 August 1971
Categories: C.2, D.1, D.3, G.1
Updates: none
Obsoletes: none

コメントを求めるワーキンググループA.マッケンジー要求をネットワークでつないでください: 215 BBN NIC#7545の1971年8月30日のカテゴリ: C.2、D.1、D.3、G.1アップデート: Obsoletesのいずれも:でない なし

                         NCP, ICP, and TELNET:

NCP、ICP、およびtelnet:

                    The Terminal IMP Implementation

端末の悪童実現

       By early December there will be six Terminal IMPs incorporated
into the network, with additional Terminal IMPs scheduled for delivery
at a rate of about one per month thereafter.  For this reason the
implementation of network protocols (and deviations from them) may be of
interest to the network community.  This note describes the choices made
by the Terminal IMP system programmers where choices are permitted by
the protocols, and documents some instances of non-compliance with
protocols.

ネットワークに組み入れられた6Terminal IMPsが12月前半までにあるでしょう、追加Terminal IMPsがその後配送のために1カ月あたりおよそ1つのレートで予定されている状態で。 この理由で、ネットワーク・プロトコル(そして、それらからの逸脱)の実現はネットワーク共同体に興味があるかもしれません。 この注意は、選択がプロトコルによって受入れられるところでTerminal IMPシステム・プログラマによってされた選択について説明して、プロトコルで不承諾のいくつかの例を記録します。

     Most of the choices made during protocol implementation on the
Terminal IMP were influenced strongly by storage limitations.  The
Terminal IMP has no bulk storage for buffering, and has only 8K of 16-
bit words available for both device I/O buffers and program.  The
program must drive up to 64 terminals which generally will include a
variety of terminal types with differing code sets and communication
protocols (e.g., the IBM 2741 terminals).  In addition, the Terminal IMP
must include a rudimentary language processor which allows a terminal
user to specify parameters affecting his network connections.  Since the
Terminal IMP exists only to provide access to the network for 64
terminals, it must be prepared to maintain 128 (simplex) network
connections at any time; thus each word stored in the NCP tables on a
per-connection basis consumes a significant portion of the Terminal IMP
memory.

格納制限でプロトコル実現の間にTerminal IMPでされた選択の大部分は強く影響を及ぼされました。 Terminal IMPはバッファリングのための大容量記憶装置を全く持っていなくて、また装置入出力バッファとプログラムの両方に利用可能な16噛み付いている単語の8Kしか持っていません。 プログラムは一般に、異なったコードセットでさまざまな端末のタイプを含んでいる最大64台の端末と通信プロトコル(例えば、2741年のIBM端末)を追い立てなければなりません。 さらに、Terminal IMPは端末ユーザが彼のネットワーク接続に影響しながらパラメータを指定できる初歩的な言語プロセッサを含まなければなりません。 Terminal IMPが存在しているので、ネットワークへのアクセスを64台の端末に供給するいつでも128人の(シンプレクス)ネットワーク接続を維持するのは準備していなければなりません。 したがって、1接続あたり1個のベースにNCPテーブルに格納された各単語はTerminal IMPメモリの重要な部分を消費します。

     It should be remembered that the Terminal IMP is designed to
provide access to the network for its users, not to provide service to
the rest of the network.  Thus the Terminal IMP does not contain
programs to perform the "server" portion of the ICP; in fact, it does
not have a "logger" socket.

Terminal IMPがネットワークの残りに対するサービスを提供するのではなく、ネットワークへのアクセスをユーザに提供するように設計されたのが覚えていられるべきです。 したがって、Terminal IMPはICPの「サーバ」一部を実行するプログラムを含んでいません。 事実上、それは「きこり」ソケットを持っていません。

                                                                [Page 1]

RFC #215

[1ページ] RFC#215

     The Terminal IMP program currently implements only the NCP, the
ICP, and the TELNET protocol since these are of immediate interest to
the sites with Terminal IMPs.  It is anticipated that portions of the
data transfer protocol will be implemented in the future; the portions
to be implemented are not yet clearly defined, but will probably include
the infinite bit stream (first) and the "transparent" mode (later).
Developments in the area of data transmission protocol will be
documented in the future.

これらが即座にTerminal IMPsとのサイトにおもしろいので、Terminal IMPプログラムは現在、NCP、ICP、およびTELNETプロトコルだけを実行します。 データ転送プロトコルの部分が将来実行されると予期されます。 実行されるべき部分は、まだ明確に定義されていませんが、(後で)たぶん無限のビットストリーム(最初に)と「透明な」モードを含むでしょう。 データ伝送プロトコルの領域での開発は将来、記録されるでしょう。

     The remainder of this note describes, and attempts to justify,
deviations from the official protocols and other design choices of
interest.  Although written in the present tense, there are some
additional known instances of deviation from protocol which will be
corrected in the near future.

この注意の残りが説明して、正当化する試み、公式のプロトコルからの逸脱、および他が選択を設計する、関心。 現在時制に書かれていますが、近い将来修正されるプロトコルからの逸脱のいくつかの追加知られている例があります。

   A)  Deviations from Protocols

a) プロトコルからの逸脱

      1)  The Terminal IMP does not guarantee correct response
          to ECO commands.  If some Host A sends a control
          message containing ECOs to the Terminal IMP, and the
          message arrives at a time when

1) Terminal IMPはECOコマンドへの正しい応答を保証しません。 いくらかのHost AがTerminal IMPにECOsを含むコントロールメッセージを送って、メッセージが一度に到着する、いつ

          a)  the Terminal IMP has a free buffer and

そしてa) Terminal IMPには無料のバッファがある。

          b)  the control link from the Terminal IMP to Host A
              is not blocked

b) コントロールTerminal IMPからHost Aへのリンクは妨げられません。

          then the Terminal IMP will generate a correct ERP for
          each ECO.  In all other cases the ECO commands will
          be discarded.  (All control messages sent by the
          Terminal IMP begin with a NOP control command, so if
          Host A sends a control message consisting of 60 ECO
          commands, the Terminal IMP will answer (if at all)
          with a 121-byte message -- 1 NOP and 60 ERPs.)

次に、Terminal IMPは各ECOのために正しいERPを発生させるでしょう。全部で、ECOが命令する他のケースは捨てられるでしょう。 (したがって、Host Aが60のECOコマンドからコントロールメッセージを成らせると、Terminal IMPは121バイトのメッセージで答えるでしょう(せいぜい)--Terminal IMPによって送られたすべてのコントロールメッセージがNOP制御コマンドで始まって、1NOPと60ERPs)

          The reason for this method of implementation is that
          to guarantee correct response to ECO in all cases
          requires an infinite amount of storage.  For
          example, suppose Host A sends control messages, each
          containing an ECO command, to Host B at the rate of
          one per second, but that Host A accepts messages from
          the network as slowly as possible (one every 39
          seconds, say).  Then Host B has only three choices
          which do not violate protocol:

実現のこの方法の理由はすべての場合でECOへの正しい応答を保証するのが無限の量の格納を必要とするということです。 例えば、Host Aがコントロールメッセージを送ると仮定してください、それぞれECOコマンドを含んでいて、Host Aがネットワークからメッセージをできるだけゆっくり(ある39秒毎と、たとえば)受け入れていなくて1秒あたり1つのレートにおけるHost Bに。 次に、Host Bには、プロトコルに違反しない3つの選択しかありません:

          a)  Declare itself dead to the network (i.e., turn
              off its Ready line), thereby denying all its
              users use of the network.

a) それ自体がネットワークに死んでいると宣言してください(すなわち、Ready線をオフにしてください)、その結果、すべてのユーザに対してネットワークの使用を否定します。

                                                                [Page 2]

RFC #215

[2ページ] RFC#215

          b)  Refuse to accept messages from the network
              faster than the slowest possible foreign Host
              (i.e., about one every 39 seconds).  If Host B is
              a Terminal IMP, this is almost certainly slow
              enough to soon reach a steady state of no users.

b) ネットワークからメッセージを可能な限り遅い外国Host(すなわち、1つに関する39秒毎)より速く受け入れるのを拒否してください。 Host BがTerminal IMPであるなら、これはほぼ確実にすぐユーザがない定常状態に達するほど遅いです。

          c)  Implement "infinite" storage for buffering
              messages.

c) メッセージをバッファリングするための「無限」の格納を実行してください。

          Since it is clear that none of the "legal" solutions
          are possible, we have decided to do no buffering,
          which should (we guess) satisfy the protocol well
          over 99% of the time.

「法的な」解決策のいずれも可能でないことが、明確であるので、私たちは、バッファリングでないの(上手にプロトコルを満たすべきである(私たちは推測します)時間の99%以上のもの)をすると決めました。

      2)  The Terminal IMP does not guarantee to issue CLS
          commands in response to "unsolicited" RFCs.  There
          are currently several ways to "solicit" an RFC, as
          follows:

2) Terminal IMPは、「求められていません、な」RFCsに対応してCLSにコマンドを発行するのを保証しません。 現在、RFCに「請求する」いくつかの方法が以下の通りあります:

          a)  A terminal user can tell the Terminal IMP to
              perform the ICP to the TELNET Logger at some
              foreign Host.  This action "solicits" the RFCs
              defined by the ICP.

a) 端末ユーザは、いくらかの外国HostでTELNET LoggerにICPを実行するようにTerminal IMPに言うことができます。 この動作はICPによって定義されたRFCsに「請求します」。

          b)  A terminal user can send an RFC to any particular
              Host and socket he chooses.  This "solicits" a
              matching RFC.

b) 端末ユーザは彼が選ぶどんな特定のHostとソケットにもRFCを送ることができます。 これは合っているRFCに「請求します」。

          c)  A terminal user can set his own receive socket
              "wild."  This action "solicits" an STR from
              anyone to his socket.  Similarly, the user can
              set his send socket "wild" to "solicit" an RTS.

c) 彼自身端末ユーザ缶の設定しているのはソケット「荒野」を受けます。 この動作はだれからも彼のソケットまでSTRに「請求します」。 同様に、ユーザ缶の設定している彼のものは、RTSに「請求する」ためにソケット「荒野」を送ります。

          If the Terminal IMP receives a "solicited" RFC it
          handles it in accordance with the protocol.  If the
          Terminal IMP receives a control message containing
          one or more "unsolicited" RFCs it will either issue
          CLS commands or ignore the RFCs according to the
          criteria described above for answering ECOs (and for
          the same reasons).  Further, if the Terminal IMP
          does issue a CLS in response to an unsolicited RFC
          it will not wait for a matching CLS before
          considering the sockets involved to be free for other
          use.

Terminal IMPが「請求された」RFCを受けるなら、プロトコルによると、それはそれを扱います。 Terminal IMPが1「求められていません、な」RFCsを含むコントロールメッセージを受け取ると、ECOs(そして同じ理由で)に答えるために上で説明された評価基準に従って、それは、CLSにコマンドを発行するか、またはRFCsを無視するでしょう。 さらに、Terminal IMPが求められていないRFCに対応してCLSを発行するなら、他の使用に自由になるようにかかわるソケットを考える前に、それは合っているCLSを待っていません。

      3)  After issuing a CLS for a connection, the Terminal
          IMP will not wait forever for a matching CLS.
          There are two cases:

3) 接続のためにCLSを発行した後に、Terminal IMPはいつまでも、合っているCLSを待っていません。 2つのケースがあります:

                                                                [Page 3]

RFC #215

[3ページ] RFC#215

          a)  The Terminal IMP has sent an RFC, grown tired of
              waiting for a matching RFC, and therefore issued
              a CLS

a) Terminal IMPはRFCを送って、合っているRFCを待つのが疲れるようになって、したがって、CLSを発行しました。

          b)  The Terminal IMP has sent a CLS for an
              established connection (matching RFCs exchanged)

b) Terminal IMPは確立した接続のためにCLSを送りました。(RFCsが交換したマッチング)

          In either of these cases the Terminal IMP will wait
          for a matching CLS for a "reasonable" time (probably
          30 seconds to one minute) and will then "forget" the
          connection.  After the connection is forgotten, the
          Terminal IMP will consider both sockets involved to
          be free for other use.

これらのケースのどちらかでは、Terminal IMPは「妥当な」時間(たぶん30秒から1分)、合っているCLSを待っています、そして、そして、接続は「忘れるでしょう」。 接続が忘れられた後に、Terminal IMPは他の使用に自由になるようにかかわる両方のソケットを考えるでしょう。

          Because of program size and table size restrictions,
          the Terminal IMP assigns socket numbers to a terminal
          as a direct function of the physical address of the
          terminal.  Thus (given this socket assignment scheme)
          the failure of some foreign Host to answer a CLS
          could permanently "hang" a terminal.  It might be
          argued that the Terminal IMP could issue a RST to the
          offending Host, but this would also break the
          connections of other terminal users who might be
          performing useful work with that Host.

プログラムサイズとテーブル・サイズ制限のために、Terminal IMPは端末の物理アドレスの一次関数としてソケット番号を端末に割り当てます。 したがって(このソケット課題計画を与える)、いくらかの外国HostがCLSに答えない場合、永久に、端末を「掛かるかもしれません」。 Terminal IMPが怒っているHostにRSTを発行できたと主張されるかもしれませんが、また、これはそのHostとの実質的な仕事を実行しているかもしれない他の端末ユーザの接続を調教するでしょう。

      4)  The Terminal IMP ignores all RET commands.  The
          Terminal IMP cannot buffer very much input from the
          network to a given terminal due to core size
          limitations.  Accordingly, the Terminal IMP allocates
          only one message and a very small number of bits
          (currently 120 bits; eventually some number in the
          range 8-4000, based on the terminal's speed) on each
          connection for which the Terminal IMP is the
          receiver.  Given such small allocations, the Terminal
          IMP attempts to keep the usable bandwidth as high as
          possible by sending a new allocation, which brings
          the total allocation up to the maximum amount, each
          time that:

4) Terminal IMPはすべてのRETコマンドを無視します。 Terminal IMPはコアサイズ制限のため非常に多くのネットワークから与えられた端末までの入力をバッファリングできません。 それに従って、Terminal IMPが1つのメッセージと非常に少ない数のビットだけを割り当てる、(現在の120ビット。 8-4000に及んでください、ベースです。結局中の何らかの数、端末の速度) Terminal IMPが受信機である各接続のときに. 与えられたあれほど小さい配分(使用可能な帯域幅が総配分を最大の量までもたらすできるだけ発信することによって高い新しい配分であることを保つTerminal IMP試み)はそれぞれそれを調節します:

          a)  one of the two buffers assigned to the terminal
              is empty, and

そしてa) 端末に割り当てられた2つのバッファの1つが空である。

          b)  the allocations are below the maxima.

b) maximaの下に配分があります。

          Thus, if a spontaneous RET were received, the
          reasonable thing for the Terminal IMP to do would be
          to immediately issue a new ALL.  However, if a
          foreign Host had some reason for issuing a first

したがって、Terminal IMPがする妥当なことは自然発生的なRETを受け取るなら、すぐに新しいすべてを発行することです。 しかしながら、外国Hostに何かがあったなら、第1を発行するには、推論してください。

                                                                [Page 4]

RFC #215

[4ページ] RFC#215

          spontaneous RET, it would probably issue a second RET
          as soon as it received the ALL.  This would be likely
          to lead to an infinite (and very rapid) RET-ALL loop
          between the two machines, chewing up a considerable
          portion of the Terminal IMP's bandwidth.  Since the
          Terminal IMP can't "afford" to communicate with such
          a Host, it ignores all RETs.

自然発生的なRET、受信するとすぐに、たぶん第2のRETを発行するだろう、すべて。 これは2台のマシンの間の無限の、そして、(非常に急速)のRETすべて、輪に通じそうでしょう、Terminal IMPの帯域幅のかなりの部分をかみ砕いて。 Terminal IMPが、そのようなHostとコミュニケートするのを「都合することができない」ので、それはすべてのRETsを無視します。

      5)  The Terminal IMP ignores all GVB commands.
          Implementation of GVB appears to require an
          unreasonable number of instructions and, at the
          moment at least, no Host appears to use the GVB
          command.  If we were to implement GVB we would always
          RET all of both allocations and this doesn't seem
          very useful.

5) Terminal IMPはすべてのGVBコマンドを無視します。 GVBの実現は無理な数の指示を必要とするように見えます、そして、現在、少なくとも、どんなHostもGVBコマンドを使用するように見えません。 私たちがGVBを実行するならいつもそうする、RET、配分とこの両方のすべてが非常に役に立つように見えません。

      6)  The Terminal IMP does not handle a total bit-
          allocation greater than 65,534 (2^16-2) correctly.
          If the bit-allocation is ever raised above 65,534 the
          Terminal IMP will treat the allocation as infinite.
          This treatment allows the Terminal IMP to store the
          bit allocation for each connection in a single word,
          and to avoid double precision addition and
          subtraction.  Our reasons for this decision are:

6) Terminal IMPは正しく総ビット配分より多くの65,534(2^16-2)を扱いません。 ビット配分が今までに6万5534より上まで上げられると、Terminal IMPは無限の同じくらい配分を扱うでしょう。 この処理で、Terminal IMPは各接続のために一語に噛み付いている配分を格納して、倍精度足し算と引き算を避けます。 私たちのこの決定の理由は以下の通りです。

      a)  A saving of more than 100 words of memory which
          would be required for allocation tables and for
          double precision addition/subtraction routines.

a) そうするメモリの100以上の単語の節約が割付表と倍精度添加/引き算ルーチンに必要です。

      b)  Our experience, which indicates that very few
          Hosts (probably one at most) ever raise their
          total bit allocation above 65,534 bits.

b) 私たちの経験であり、どれが、非常にわずかなHosts(たぶん高々1)しか彼らの合計を上げないのを示すかが6万5534ビットより上での配分に噛み付きました。

      c)  Our expectation that any Host which ever raises
          its bit allocation above 65,534 probably would be
          willing to issue an infinite bit allocation if
          one were provided by the protocol.  Once the bit
          allocation is greater than about 16,000, the
          message allocation (which the Terminal IMP
          handles correctly) is a more powerful method of
          controlling network loading of a Host system than
          bit allocation.  We believe that Hosts which have
          loading problems will recognize this.

c) プロトコルは1であるなら噛み付いている6万5534より上での配分を上げるどんなHostも発行しても構わないと無限の噛み付いている配分をたぶん思っている私たちの期待を提供しました。 噛み付いている配分がいったんおよそ1万6000以上になると、メッセージ配分(Terminal IMPが正しく扱う)はHostシステムのネットワークローディングを制御する噛み付いている配分より強力な方法です。 私たちは、ローディング問題を持っているHostsがこれを認識すると信じています。

      7)  The Terminal IMP ignores the "32-bit number" in the
          ICP.  When the Terminal IMP (the "user site")
          initiates the Initial Connection Protocol the actual
          procedure is to send the required RTS to the logger

7) Terminal IMPはICPで「32ビットの数」を無視します。 Terminal IMP(「ユーザの現場」)が実際の手順が必要なRTSを送ることになっているInitial Connectionプロトコルをきこりに開始するとき

                                                                [Page 5]

RFC #215

[5ページ] RFC#215

          socket of the user-specified foreign Host and
          simultaneously to set the terminal user's send and
          receive sockets in a state where each will accept
          any RFC from the specified Host.  The 32-bit socket
          number transmitted over the logger connection is
          ignored, and the first RTS and STR addressing the
          user's sockets will be accepted (and answered with
          matching RFCs).

そして、ユーザによって指定された外国Hostのソケット、同時、端末ユーザのものを設定するために、それぞれが指定されたHostからどんなRFCも受け入れる状態でソケットを送って、受けてください。 きこりの接続の上に伝えられた32ビットのソケット番号を無視します、そして、ユーザのソケットを記述する最初のRTSとSTRを受け入れるでしょう(そして、合っているRFCsと共に答えられます)。

          The ICP allows the foreign Host to transmit the RFCs
          involving Terminal IMP sockets "U+2" and "U+3" at
          any time after receipt of the RFC to the (foreign
          Host's) logger socket.  In particular, the RFCs may
          arrive at the Terminal IMP before the 32-bit
          number.  In the case of a "normal" foreign Host, the
          first incoming RFCs for sockets U+2 and U+3 will come
          from the sockets indicated by the 32-bit number, so
          it doesn't matter if the number is ignored.  In the
          case of a pathologic foreign Host, a potentially
          infinite number of "wrong" RFCs involving U+2 and
          U+3 may arrive at the Terminal IMP before the 32-bit
          number is sent.  The Terminal IMP would be required
          to store this stream of RFCs pending arrival of the
          32-bit number, then issue CLS commands for all
          "wrong" RFCs.  However, the Terminal IMP does not
          have infinite storage available for this purpose (it
          is also doubtful that a terminal user really wants to
          converse with a pathologic foreign Host) so the
          Terminal IMP assumes that the foreign Host is
          "normal" and ignores the 32-bit number.

ICPは外国HostにRFCの領収書の後にいつでもTerminal IMPソケット「U+2」と「U+3」に(異種宿主のもの)きこりのソケットにかかわるRFCsを伝えさせます。 特に、RFCsは32ビットの数の前にTerminal IMPに到着するかもしれません。 外国「正常な」Hostの場合では、ソケットU+2とU+3のための最初の入って来るRFCsが32ビットの数によって示されたソケットから来るので、数が無視されるかどうかは重要ではありません。 pathologic外国Hostの場合では、32ビットの数を送る前に潜在的に無限の数のU+2にかかわる「間違った」RFCsとU+3がTerminal IMPに届くかもしれません。 Terminal IMPは32ビットの数の到着までRFCsのこの流れを格納しなければならなくて、次に、問題CLSはすべての「間違った」RFCsのために命令します。 しかしながら、Terminal IMPにはこの目的に有効な無限の格納がなくて(また、端末ユーザが本当にpathologic外国Hostと話したがっているのも、疑わしいです)、Terminal IMPは、外国Hostが「正常である」と仮定するので、32ビットの数を無視します。

   B)  Other Design Choices Related to Protocol

B) プロトコルに関連する他のデザイン選択

          1)  The Terminal IMP ignores incoming ERR commands and
              does not output ERR commands.

1) Terminal IMPは入って来るERRコマンドを無視して、ERRコマンドを出力しません。

          2)  The Terminal IMP assumes that incoming messages have
              the format and contents demanded by the relevant
              protocols.  For example, the byte size of incoming
              TELNET messages is assumed to be 8.  The major checks
              which the Terminal IMP does make are:

2) Terminal IMPは、関連プロトコルから形式とコンテンツを要求すると入力メッセージで仮定します。 例えば、入って来るTELNETメッセージのバイトサイズは8であると思われます。 Terminal IMPがする主要なチェックは以下の通りです。

              a)  If an incoming control message has a byte count
                  greater than 120 then it is discarded.

a) 1バイトが入って来るコントロールメッセージで120以上を数えるなら、捨てられます。

                                                                [Page 6]

RFC #215

[6ページ] RFC#215

              b)  If a control command opcode greater than 13 is
                  found during the processing of a control message
                  then the remainder of the control message is
                  discarded.

b) 制御コマンドopcodeより多くの13がコントロールメッセージの処理の間、見つけられるなら、コントロールメッセージの残りは捨てられます。

              c)  If an incoming data message has a byte count
                  indicating that the bit allocation for the
                  connection is exceeded (based on the assumed byte
                  size) then the message is discarded.

c) 受信データメッセージが接続のための噛み付いている配分が超えられているのを(想定されたバイトサイズに基づいています)示しながら1バイトが重要にするなら、メッセージは捨てられます。

          3)  If one control message contains several RST commands
              only one RRP is transmitted.  If several control
              messages, each containing RST commands, arrive "close
              together" only one RST is returned.  [The actual
              implementation is to set a bit each time a RST is
              found (in "foreground") and to reset the bit when a
              RRP is sent (in "background").]

3) 1つのコントロールメッセージがいくつかのRSTコマンドだけを含んでいるなら、1RRPが伝えられます。 それぞれRSTコマンドを含んでいて、いくつかのコントロールメッセージが到着するなら、「一緒に閉鎖」だけ1RSTを返します。 [実際の実現はRSTを見つけて(「フォアグランド」で)、RRPであるときにビットをリセットさせるたびに(「バックグラウンド」で)少しセットすることです。]

          4)  Socket numbers are preassigned based on the hardware
              "physical address" (in the terminal multiplexing
              device) of the terminal.  The high order 16 bits of
              the socket number give the device number (in the
              range 0-63) and the low order bits are normally 2 or
              3 depending on the socket's gender (zero is also used
              during ICP).  [We would be pleased to see socket
              number length reduced to 16 bits; in that case the
              high order 8 bits would be mapped to the device and
              the low order 8 bits would contain 2 or 3.]

4) ソケット番号は「物理アドレス」(端末のマルチプレクシング装置の)という端末のハードウェアに基づいた状態で「前-割り当て」られます。 ソケット番号の16ビットが装置番号(範囲0-63の)を与える高位と下位のビットは、ソケットの性に依存する通常2か3(また、ゼロはICPの間、使用される)です。 [私たちはソケット数の長さは16ビットまで減少しました; その場合、高位8ビットが装置と下位に8ビット写像されるのがわかるのが2か3を含むのをうれしく思うでしょう。]

          5)  During ICP, with the Terminal IMP as the user site,
              the Terminal IMP follows the "Listen" option rather
              than the "Init" option (as described at the top of
              page 3, NIC #7170).  In other words, the Terminal IMP
              does not issue the RFCs involving sockets U+2 and U+3
              except in response to incoming RFCs involving those
              sockets.  In this context, we will mention that the
              "deadlock" mentioned in NWG-RFC #202 does not exist,
              since the ICP does not give the server the "Listen"
              option (see NIC #7170, page 2).

5) ICPの間、ユーザの現場としてのTerminal IMPと共に、Terminal IMPは「イニット」オプションよりむしろ「聴いてください」というオプションに続きます(3、7170年ページのNIC#上部で説明されるように)。 言い換えれば、Terminal IMPはそれらのソケットにかかわる入って来るRFCs以外に、ソケットU+2とU+3にかかわるRFCsを発行しません。 このような関係においては、私たちは、NWG-RFC#202で言及した「行き詰まり」が存在しないと言及するつもりです、ICPが「聴いてください」というオプションをサーバに与えないので(NIC#7170を見てください、2ページ)。

          [ This RFC was put into machine readable form for entry ]
            [ into the online RFC archives by Randy Dunlap 5/97 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ランディ・ダンラップ5/97によるオンラインRFCアーカイブへの]

                                                                [Page 7]

[7ページ]