RFC54 日本語訳

0054 Official Protocol Proffering. S.D. Crocker, J. Postel, J.Newkirk, M. Kraley. June 1970. (Format: TXT=20131 bytes) (Updated by RFC0057) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                               Steve Crocker (UCLA)
Request for Comments # 54                              Jon Postel (UCLA)
June 18, 1970                                     John Newkirk (Harvard)
                                                   Mike Kraley (Harvard)

ネットワークワーキンググループスティーブクロッカー(UCLA)は1970年6月18日のコメント#54ジョン・ポステル(UCLA)のためにジョン・ニューカーク(ハーバード)マイクKraleyを要求します。(ハーバード)

                    An Official Protocol Proffering

公式のプロトコル提供

I. INTRODUCTION

I. 序論

   As advertised in NEW/RFC #53, we are submitting the protocol herein
   for criticism, comments, etc.  We intend for this protocol to become
   the initial official protocol, and will, therefore, be happiest if no
   serious objections are raised.  Nevertheless, we will entertain all
   manner of criticism until July 13, 1970, and such criticism should be
   published as a NWG/RFC or directed to the first author.

NEW/RFC#53に広告に掲載されているように、私たちは批評、コメントなどのためにここにプロトコルを提出しています。 私たちは、このプロトコルが初期の公式のプロトコルになるつもりであり、したがって、どんな重大な反論も高くしないなら、最も幸福になるでしょう。 それにもかかわらず、1970年7月13日、およびそのような批評がNWG/RFCとして発行されるべきであるか、または第1代作者に向けられるべきであるまで、私たちは批評のすべての方法を楽しませるつもりです。

   After July 13, a decision will be made whether to adopt this protocol
   (or slight variation) or whether to redesign it and resubmit it for
   criticism.

7月13日後に、このプロトコル(または、わずかな変化)を採用するかどうか、それを再設計して、または批評のためにそれを再提出するかどうかという決定をするでしょう。

Only the Protocol

プロトコルだけ

   In preceding discussions of protocol, no clear distinction has been
   made between the network-wide specifications and local strategies.
   We state here that the only network-wide issues are message formats
   and restrictions on message content.  Implementation of a Network
   Control Program (NCP) and choice of system calls are strictly local
   issues.

プロトコルの議論に先行する際に、ネットワーク全体の仕様とローカルの戦略の間で明らかな区別を全くしていません。 私たちは、ここに唯一のネットワーク全体の問題がメッセージ内容におけるメッセージ・フォーマットと制限であると述べます。 Network Control Program(NCP)の実現とシステムコールの選択は厳密にローカルの問題です。

   This document is constrained to cover only network-wide issues and
   thus will not treat system calls or NCP tables; nevertheless, a
   protocol is useless without an NCP and a set of system calls, so we
   have expended a great deal of effort in deriving a protypical NCP.
   This effort is reported in NWG/RFC #55, and the reader should
   correlate the protocol presented here with the suggestions for using
   it presented there.  It is important to remember, however, that the
   content of NWG/RFC #55 is only suggestive and that competitive
   proposals should be examined before choosing an implementation.

このドキュメントは、ネットワーク全体の問題だけをカバーするのが抑制されて、その結果、システムコールかNCPテーブルを扱わないでしょう。 それにもかかわらず、プロトコルがNCPとシステムコールのセットなしで役に立たないので、私たちはprotypical NCPを引き出しながら、大きな努力を使いました。 この努力はNWG/RFC#55で報告されます、そして、読者はここにそれがそこに提示した使用のための提案で提示されたプロトコルを関連させるべきです。 しかしながら、NWG/RFC#55の内容が思わせ振りであるだけであり、実現を選ぶ前にコンペに出す企画案が調べられるべきであったのを覚えているのは重要です。

Flow Control

フロー制御

   In the course of designing this current protocol, we have come to
   understand that flow control is more complex than we imagined.  We
   now believe that flow control techniques will be one of the active
   areas of concern as the network traffic increases.  We have,
   therefore, benefitted from some ideas stimulated by Richard Kaline
   and Anatol Holt and have modified the flow control procedure.
   (Defects in our scheme are, of course, only our fault).  This new

この現在のプロトコルを設計することの間に、私たちはフロー制御が私たちが想像したより複雑であることを理解するようになりました。 私たちは、現在、ネットワークトラフィックが増加するのに応じてフロー制御のテクニックが関心の活動領域の1つになると信じています。 私たちは、したがって、リチャード・ケーラインとアナトール・ホルトによって刺激されたいくつかの考えの利益を得て、フロー制御手順を変更しました。 (私たちの計画における欠陥はもちろん私たちのせいにすぎません。) これほど新しいです。

Crocker, Postel, Newkirk & Kraley                              [Page 1]

RFC 54              An Official Protocol Proffering        18 June 1970

クロッカー、ポステル、ニューカーク、および1970年6月18日を提供する公式のプロトコルあたりKraley[1ページ]RFC54

   procedure has demonstrable limitations, but has the advantages that
   it is more cleanly implementable and will support initial network
   use.  This is the only substantive change from the protocol already
   agreed upon.

手順によって、明白な制限を持っていますが、利点は、より清潔に実行可能されます、そして、初期のネットワーク使用を支持するでしょう。 これは既に同意されたプロトコルからの唯一の実質的な変化です。

   The new flow control mechanism requires the receiving host to
   allocate buffer space for each connection and to notify the sending
   host of how much space in bits is available.  The sending host keeps
   track of how much room is available and never sends more text than it
   believes the receiving host can accept.

新しいフロー制御メカニズムは、受信ホストが各接続のためにバッファ領域を割り当てて、ビットのどのくらいのスペースが利用可能であるかについて送付ホストに通知するのを必要とします。 送付ホストは、どのくらいの余地が利用可能であるかに関する道を保って、受け入れることができるよりそれが、受信ホストを信じている多くのテキストを決して送りません。

   To implement this mechanism, the sending host keeps a counter
   associated with each connection.  The counter is initialized to zero,
   increased by control commands sent from the receiving host, and
   decremented by the text length of any message sent over the
   connection.  The sending host is prohibited from sending text longer
   than the value of the counter, so the counter never goes below zero.

このメカニズムを実行するために、送付ホストは、各接続にカウンタを関連づけ続けます。 カウンタは、ゼロに初期化されて、受信ホストから送られた制御コマンドによって増加されて、接続の上に送られたどんなメッセージのテキストの長さでも減少します。 送付ホストがカウンタの値より長い間テキストを送るのが禁止されているので、カウンタは零下に決して行きません。

   Ideally, the receiving host will allocate some buffer space as soon
   as the connection is established.  The amount allocated must never
   exceed what the receiver can guarantee to accept.  As text arrives,
   it occupies the allocated buffer space.  When the receiving process
   absorbs the waiting text from the buffer, the NCP fires back a new
   allocation of space for that connection.  The NCP may allocate space
   even if the receiving process has not absorbed waiting text if it
   believes that extra buffer space is appropriate.  Similarly, the NCP
   may decide not to reallocate buffer space after the receiving process
   makes it available.

理想的に、接続が確立されるとすぐに、受信ホストは何らかのバッファ領域を割り当てるでしょう。 割り当てられた量は受信機が受け入れるのを保証できるものを決して、超えてはいけません。 テキストが到着するとき、それは割り当てられたバッファ領域を占領します。 受信の過程がバッファから待ちテキストを吸収するとき、NCPはその接続のためにスペースの新しい配分を撃ち返します。 余分なバッファ領域が適切であることが信じているなら受信の過程が待ちテキストを吸収していなくても、NCPはスペースを割り当てるかもしれません。 同様に、NCPは、受信の過程で利用可能になった後にバッファ領域を再割当てしないと決めるかもしれません。

   The control command which allocates space is

スペースを割り当てる制御コマンドはそうです。

                   ALL     <link>  <space>

すべての<リンク><スペース>。

   This command is sent only from the receiving host to the sending
   host.

受信ホストだけから送付ホストにこのコマンドを送ります。

   This formulation of flow control obviates the RSM and SPD commands in
   NWG/RFC #36, and the Host-to-Imp message type 10 and Imp-to-Host
   message types 10 and 11 in the current revision of BBN Report 1822.

フロー制御のこの定式化はNWG/RFC#36でRSMとSPDコマンドを取り除きます、そして、Hostから悪童へのメッセージタイプ10とImpからホストへのメッセージはBBN Report1822の現在の改正に10と11をタイプします。

   The obvious limitation in this scheme is that the receiving host is
   not permitted to depend upon average buffer usage -- worse case is
   always assumed.  If only a few connections are open, it is unlikely
   that there would be much savings.  However, for more than a few
   connections, average buffer usage will be much less than allocated
   buffer space.  We have looked at extensions of this protocol which
   would include adaptive allocation, and we believe this to be
   feasible.  For the present this limited scheme seems best, and we

この計画における明白な制限は受信ホストが平均したバッファの使用状況によることが許可されていないということです--より悪いケースはいつも想定されます。 ほんのいくつかの接続がオープンであるなら、多くの貯蓄があるのは、ありそうもないです。 しかしながら、平均したバッファの使用状況はバッファ領域を割り当てるよりかなり多くの接続には、はるかに少なくなるでしょう。 私たちは適応型の配分を含んでいるこのプロトコルの拡大を見ました、そして、これが可能であると信じています。 当分、この限られた計画は最善、および私たちに見えます。

Crocker, Postel, Newkirk & Kraley                              [Page 2]

RFC 54              An Official Protocol Proffering        18 June 1970

クロッカー、ポステル、ニューカーク、および1970年6月18日を提供する公式のプロトコルあたりKraley[2ページ]RFC54

   look forward to discussing more sophisticated schemes later.  The old
   scheme of special RFNM's, etc. also remains under discussion.

後でより洗練された計画について議論するのを楽しみにしてください。 特別なRFNMのものの古い計画であり、また、などは議論を下回っています。

   In order to answer questions and discuss details, we will hold a pair
   of network meetings.  The first will be on June 29 at Harvard and the
   second on July 1 at UCLA.  We request that no more than on programmer
   per host attend a meeting and that hosts be represented at only one
   of these meetings.  Two of us (J.N. and S.C.) will be at both
   meetings.

質問に答えて、詳細について議論するために、私たちは1組のネットワーク会合を開くつもりです。 1番目がハーバードと6月29日7月1日秒にUCLAにあるでしょう。 私たちは1ホストあたりのプログラマの上にミーティングに出席するよりそれをもう少しでない要求します、そして、ホストは1だけ時にこれらのミーティングについて代理をされます。 私たち(J.N.とサウスカロライナ州)の2が両方のミーティングにあるでしょう。

   To make reservations to attend the Harvard meeting, contact

ハーバードのミーティング、接触に出席する予約をするように

   Mrs. Margi Robison
   (617) 495-3989
      or 495-3991

Margiロビソン(617)495-3989か495-3991夫人

   To make reservations to attend the UCLA meeting, contact Mrs. Benita
   Kirstel (213) 825-2368.

UCLAミーティングに出席するために予約をするには、ベニータKirstel(213)825-2368夫人に連絡してください。

II. THE PROTOCOL

II。 プロトコル

   The notion of a connection as explained in NWG/RFC #33 pervades the
   protocol.  A connection is a simplex communication path, intended to
   be between two processes.

NWG/RFC#33で説明される接続の概念はプロトコルを瀰漫させます。 接続は2つの過程の間には、あることを意図するシンプレクス通信路です。

   The primary function of the protocol is to provide for
       (1)  establishment of connections,
       (2)  regulation of flow over connections, and
       (3)  termination of connections.

プロトコルの第一の機能は(1) 接続の設立、(2) 接続の上の流れの規則、および(3) 接続の終了に備えることです。

   In addition, the protocol provides some ancillary functions such as
   sending simulated interrupt pulses and echoing test messages.

さらに、プロトコルはシミュレートされた中断パルスと反響にテストメッセージを送ることなどのいくつかの補助的機能を提供します。

   To provide a path for exchanging information about connections, we
   designate specific links, i.e. link one between each pair of hosts to
   be control links.  Traffic on control links consists only of control
   commands, defined below.

接続に関して情報交換するのに経路を提供するなら、私たちは、コントロールリンクになるように特定のリンク、すなわち、それぞれの組のホストの間のリンク1を指定します。 コントロールリンクにおける交通は以下で定義された制御コマンドだけから成ります。

   Connections are named by a pair of sockets.  Sockets are 40 bit names
   which are known throughout the network.  Each host is assigned a
   private subset of these names, and a command which requests a
   connection names one socket which is local to the requesting host and
   one local to the receiver of the request.

コネクションズは1組のソケットによって命名されます。 ソケットはネットワーク中で知られている40ビットの名前です。 これらの名前の個人的な部分集合は各ホストに割り当てられます、そして、接続を要求するコマンドは要求の受信機に地方で要求ホストと1つに地方であることの1個のソケットを任命します。

   Sockets are polarized; even numbered sockets are receive sockets; odd
   numbered ones are send sockets.  One of each is required to make a
   connection.

ソケットは分極されます。 番号付のソケットさえそうです。ソケットを受けてください。 変な番号付のものはそうです。ソケットを送ってください。 それぞれの1つが、接続を作るのに必要です。

Crocker, Postel, Newkirk & Kraley                              [Page 3]

RFC 54              An Official Protocol Proffering        18 June 1970

クロッカー、ポステル、ニューカーク、および1970年6月18日を提供する公式のプロトコルあたりKraley[3ページ]RFC54

   To facilitate transmission of information over a connection, a unique
   link is assigned to each connection.  One of the steps in
   establishing a connection, therefore, is the assignment of a link.
   Of the non-control links, zero is reserved for intra-network use, and
   links 32 to 255 are reserved for experiment and expansion.  Thus only
   links 2 through 31 are available for regular use.  Link assignment
   must either always be done by the receiver or always by the sender.
   We have (almost) arbitrarily chosen this to be the receiver's
   responsibility.

接続の上の情報伝送を容易にするために、ユニークなリンクは各接続に割り当てられます。 したがって、取引関係を築くことにおけるステップの1つはリンクの課題です。 非コントロールリンクでは、ゼロはイントラネットワーク使用のために予約されます、そして、リンク32〜255は実験と拡大のために予約されます。 したがって、リンク2〜31だけが定期的な使用に利用可能です。 受信機かいつも送付者がいつもリンク課題をしなければなりません。 私たちは、受信機の責任になるように任意にこれを(ほとんど)選びました。

   All regular messages consist of a 32 bit leader, marking, text, and
   padding.  Marking is a (possibly null) sequence of zeroes followed by
   a 1; padding is a 1 followed by a (possibly null) sequence of zeroes.

すべての通常のメッセージが32ビットのリーダー、マーク、テキスト、および詰め物から成ります。 マークは1がいうことになったゼロの(ことによるとヌル)の順序です。 詰め物は1がゼロの(ことによるとヌル)の系列で続いたということです。

   A regular message sent over the control link (link 1) is called a
   control message.  Its text is an integral (possibly zero) number of
   control commands in the form described below, and this text must end
   on a command boundary.

コントロールリンク(リンク1)の上に送られた通常のメッセージはコントロールメッセージと呼ばれます。 テキストは以下で説明されたフォームでの不可欠(ことによるとゼロ)の数の制御コマンドです、そして、本稿はコマンド限界で終わらなければなりません。

   The commands used to establish a connection are STR and RTS.  The STR
   command is sent from a prospective sender to a prospective receiver.
   Its <my socket> field contains a send socket local to the prospective
   sender; its <your socket> field contains a receive socket local to
   the prospective receiver.  The RTS command is the dual, but is also
   contains a <link> field for link assignment.  These two commands are
   referred to as requests-for-connection (RFC).  A STR and an RTS match
   if the <my socket> field of one is identical to the <your socket>
   field of the other and vice versa.  A connection is established where
   a matching pair of RFC's have been exchanged.

取引関係を築くのに使用されるコマンドは、STRとRTSです。 STRコマンドはa将来の受信機将来の送付者から私のソケット>分野が含む<に送って、aが将来の送付者にとっての、地方のソケットを送るということです。 RTSコマンドは、二元的ですが、また、二元的です。aは将来の受信機への地方のソケットを受けます。あなたのソケット>分野が含む<、リンク課題のための<リンク>分野を含んでいます。 これらの2つのコマンドが接続を求める要求(RFC)と呼ばれます。 私のソケット>がさばく1の<があなたのソケット>がさばくもう片方の<と同じであるなら、STRとRTSは合っています、そして、逆もまた同様です。 接続はRFCの合っている組を交換したところで確立されます。

   Hosts are prohibited from establishing more than one connection to
   any local socket.  Therefore, a host may not use a socket for the <my
   socket>  field of an RFC if that socket is mentioned in a previous
   RFC and the connection is not yet terminated.

ホストはどんな地方のソケットとの1つ以上の接続も確立するのが禁止されています。 したがって、そのソケットが前のRFCで言及されて、接続がまだ終えられていないなら、ホストは私のソケット>がさばくRFCの<にソケットを使用しないかもしれません。

   The command used to terminate a connection is CLS.  Each side must
   send and receive a CLS command before a connection is completely
   terminated and the sockets are free to participate in other
   connections.  It is not necessary that both RFC's be exchanged before
   a connection is terminated.  More details on termination are given
   below.

接続を終えるのに使用されるコマンドはCLSです。 接続が完全に終えられて、ソケットが無料で他の接続に参加できる前に、それぞれの側は、CLSコマンドを送って、受け取らなければなりません。 それは必要でない、そんなに両方、接続が終える前にRFCを交換しました。 終了に関するその他の詳細を以下に与えます。

   After a connection is established, the receiving host sends a ALL
   command which allocates space for the connection.  The sender keeps
   track of how much space is available in the receiving host and does
   not transmit more text than the receiving host can accept, as
   explained above.  A sender is also constrained by the local IMP from
   sending a message over a connection until  the RFNM from the previous

接続が確立された後に、受信ホストは接続のためにスペースを割り当てるすべてのコマンドを送ります。 送付者は、受信ホストにどのくらいのスペースが利用可能であるかに関する道を保って、受信ホストが受け入れることができるより多くのテキストを伝えません、上で説明されるように。 また、送付者は、メッセージを前から接続の上にRFNMまで送るので、地方のIMPによって抑制されます。

Crocker, Postel, Newkirk & Kraley                              [Page 4]

RFC 54              An Official Protocol Proffering        18 June 1970

クロッカー、ポステル、ニューカーク、および1970年6月18日を提供する公式のプロトコルあたりKraley[4ページ]RFC54

   message is received.

メッセージは受信されています。

   After a connection is established, CLS commands sent by the receiver
   and sender have slightly different effects.  CLS command sent by the
   sender indicate that no more messages will be sent over the
   connection.  This command must not be sent if there is a message in
   transit over the connection.

接続が確立された後に、受信機と送付者によって送られたCLSコマンドはわずかに異なった効果を持っています。 コマンドが送付者で送ったCLSは、それ以上のメッセージが全く接続の上に送られないのを示します。 接続の上のトランジットにメッセージがあれば、このコマンドを送ってはいけません。

   CLS commands sent by the receiver act as demands on the sender to
   terminate transmission.  However, since there is a delay in getting
   the CLS command to the sender, the receiver must expect its buffers
   to fill to the limit provided in ALL commands.

受信機によって送られたCLSコマンドはトランスミッションを終えるという送付者における要求として機能します。 しかしながら、CLSコマンドを送付者に届ける遅れがあるので、受信機は、バッファがすべてのコマンドに提供された限界にいっぱいになると予想しなければなりません。

   While a connection is established, either side may send INR or INS
   commands.  The interpretation of these commands is a local matter,
   but in general they will provide and escape function.

接続が確立されている間、どちらの側もINRかINSにコマンドを送るかもしれません。 これらのコマンドの解釈が地域にかかわる事柄ですが、一般に、それらは、機能を提供して、逃げるでしょう。

   Note that the ALL, INR and INS commands may be sent only after the
   connection is established and before a CLS command is sent.

それに注意してください、接続を確立した後とだけCLSコマンドを送る前にすべて、INRとINSコマンドを送るかもしれません。

   A very simple test facility is provided by the ECO and ERP commands.
   Upon receiving a ECO command, a host must change the first eight bits
   to ERP and return it.  These commands have no relationship to
   connections.

ECOとERPコマンドで非常に簡単なテスト機能を提供します。 ECOコマンドを受け取ると、ホストは、ERPに最初の8ビット変わって、それを返さなければなりません。 これらのコマンドには、接続との関係が全くありません。

   A NOP command is included for convenience.  It is coded as zero to
   facilitate command message construction.

NOPコマンドは便宜のために含まれています。 容易にするゼロがメッセージ工事を命令するとき、それはコード化されます。

   Finally, an ERR command is included for notifying a foreign host it
   has (apparently) made an error.  At present, no specific list of
   errors is defined, and no action is defined for the receipt of ERR
   commands.  Hosts should log ERR commands upon receipt so that system
   programmers can diagnose the trouble.  A host may generate an ERR
   command at any time and for any reason, but it is advised that each
   host publish an exhaustive list of the ERR commands it may sent and
   their interpretations.

最終的に、ERRコマンドは、それが(明らかに)誤りをした異種宿主に通知するために含まれています。 現在のところ、誤りのどんな特定のリストも定義されません、そして、動作は全くERRコマンドの領収書のために定義されません。 ホストが領収書にERRコマンドを登録するべきであるので、システム・プログラマは問題を分析できます。 ホストはいつでもであることにおいてどんな理由のでもERRコマンドを発生させるかもしれませんが、各ホストが送って、それがそうするかもしれないERRコマンドと彼らの解釈に関する完全なりストを発表すると忠告されます。

NETWORK CONTROL COMMANDS

ネットワーク制御命令

   The following is a detailed description of the structure and format
   of each of the control commands.

↓これはそれぞれの制御コマンドの構造と形式の詳述です。

   To facilitate and clarify socket descriptions, the following
   conventions have been adopted:

ソケット記述を容易にして、はっきりさせるために、以下のコンベンションは採用されました:

   <my socket> and <your socket> are used in the command descriptions.

<、あなたのソケット>が使用される私のソケットの>と<、コマンド記述。

Crocker, Postel, Newkirk & Kraley                              [Page 5]

RFC 54              An Official Protocol Proffering        18 June 1970

クロッカー、ポステル、ニューカーク、および1970年6月18日を提供する公式のプロトコルあたりKraley[5ページ]RFC54

   <my socket> is local to the originator of the command.

<、コマンドの創始者にとって、私のソケット>は地方です。

   <your socket> is local to the receiver of the command.

<、あなたのソケット>はコマンドの受信機に地方です。

CONTROL COMMAND FORMATS

制御コマンド形式

   No Operation
                      _______
                     |       |
                     |  NOP  |
                     |_______|

操作がありません。_______ | | | NOP| |_______|

   Request Connection, Receiver to Sender
                      ______________________________________________
                     |       |             |               |        |
                     |  RTS  |  my socket  |  your socket  |  link  |
                     |_______|_____________|_______________|________|

接続、受信機を送付者に要求してください。______________________________________________ | | | | | | RTS| 私のソケット| あなたのソケット| リンク| |_______|_____________|_______________|________|

   Request Connection, Sender to Receiver
                      _____________________________________
                     |       |             |               |
                     |  STR  |  my socket  |  your socket  |
                     |_______|_____________|_______________|

接続、送付者を受信機に要求してください。_____________________________________ | | | | | STR| 私のソケット| あなたのソケット| |_______|_____________|_______________|

   Close
                      _____________________________________
                     |       |             |               |
                     |  CLS  |  my socket  |  your socket  |
                     |_______|_____________|_______________|

閉鎖_____________________________________ | | | | | CLS| 私のソケット| あなたのソケット| |_______|_____________|_______________|

   Allocate
                      __________________________
                     |       |        |         |
                     |  ALL  |  link  |  space  |
                     |_______|________|_________|

割り当てます。__________________________ | | | | | すべて| リンク| スペース| |_______|________|_________|

   Interrupt Sent by Receiving Process
                      _______________
                     |      |        |
                     | INR  |  link  |
                     |______|________|

過程を受けることによって送られた中断_______________ | | | | INR| リンク| |______|________|

Crocker, Postel, Newkirk & Kraley                              [Page 6]

RFC 54              An Official Protocol Proffering        18 June 1970

クロッカー、ポステル、ニューカーク、および1970年6月18日を提供する公式のプロトコルあたりKraley[6ページ]RFC54

   Interrupt Sent by Sending Process
                     _______________
                    |      |        |
                    | INS  |  link  |
                    |______|________|

過程を送ることによって送られた中断_______________ | | | | インス| リンク| |______|________|

   Echo Request
                     ____________________________   _________
                    |       |                    \  \        |
                    |  ECO  |  length            /  /  text  |
                    |_______|____________________\  \________|

エコー要求____________________________ _________ | | \ \ | | エコ| 長さの//テキスト| |_______|____________________\ \________|

   Echo Reply
                     ____________________________   _________
                    |       |                    \  \        |
                    |  ERP  |  length            /  /  text  |
                    |_______|____________________\  \________|

エコー・リプライ____________________________ _________ | | \ \ | | ERP| 長さの//テキスト| |_______|____________________\ \________|

   Error Detected
                     ____________________________   _________
                    |       |                    \  \        |
                    |  ERR  |  length            /  /  text  |
                    |_______|____________________\  \________|

検出された誤り____________________________ _________ | | \ \ | | 間違えてください。| 長さの//テキスト| |_______|____________________\ \________|

   The host is specified in the leader.

ホストはリーダーで指定されます。

   <link> is 8 bits

<リンク>は8ビットです。

   <space> is 32 bits long and is an unsigned integer.

<スペース>は長さ32ビットであり、符号のない整数です。

   <length> is an unsigned 16 bit integer.

<の長さの>は16ビットの無記名の整数です。

   <text> is as long as the length.  The command is therefore 24 bits
   longer that the length.  Maximum length is one message, to facilitate
   command decoding and manipulation.

<テキスト>は長さと同じくらい長いです。 したがって、コマンドが24ビットより長い、それ、長さ。 最大の長さは、コマンド解読と操作を容易にするためには1つのメッセージです。

   All control command codes are 8 bit long:

すべての制御コマンドコードが長さ8ビットです:

             NOP = 0
             RTS = 1
             STR = 2
             CLS = 3
             ALL = 4
             INR = 5

2 1 0NOP=RTS=STR=CLS=3 すべての=4INR=5

Crocker, Postel, Newkirk & Kraley                              [Page 7]

RFC 54              An Official Protocol Proffering        18 June 1970

クロッカー、ポステル、ニューカーク、および1970年6月18日を提供する公式のプロトコルあたりKraley[7ページ]RFC54

             INS = 6
             ECO = 7
             ERP = 8
             ERR = 9

6エコ=7ERP=インス=8が間違える、=9

   <my socket> and <your socket> are 32 bits long,
                     _______________________
                    |               |       |
                    |  User number  |  AEN  |
                    |_______________|_______|

<、私のソケットの>と<、あなたのソケット>は長さ32ビットです。_______________________ | | | | ユーザ番号| AEN| |_______________|_______|

   24 bits for user number and 8 bits for AEN.

ユーザ番号のための24ビットとAENのための8ビット。

III.  Conclusion

III。 結論

   Extensions to the Protocol

プロトコルへの拡大

   Some issues have not been adequately treated in the current protocol.
   We have in mind the following topics to consider more thoroughly and
   perhaps experiment with.

いくつかの問題は現在のプロトコルで適切に扱われていません。 私たちは、より徹底的に考えて、恐らく実験する以下の話題を考えています。

   1. More Sophisticated Flow Control.

1. より高度なフロー制御。

   As mentioned above, other schemes for flow control are still being
   considered.  Other than the necessity of providing some form of it,
   we are completely unsure of the nature of the problem.  It may turn
   out that the present scheme is completely adequate; it may also turn
   out that we will need a much more complex scheme.

以上のように、フロー制御の他の計画はまだ考えられています。 何らかの形式のそれを提供するという必要性を除いて、私たちは問題の性格が完全に不確かです。 現在の計画が完全に適切であると判明するかもしれません。 また、私たちがはるかに複雑な計画を必要とすると判明するかもしれません。

   2. Error Detection and Recovery

2. 誤り検出と回復

   As we gain some experience with the network, we will develop a better
   understanding of what errors can occur and, perhaps more importantly,
   what to do about these errors.  We expect the protocol to change as
   we understand error control.

私たちがネットワークの何らかの経験をするのに従って、私たちはどんな誤りが発生できるか、そして、恐らくより重要にこれらの誤りに関してするべきことに関する、より良い理解を育むつもりです。 私たちは、プロトコルが私どもが理解しているところでは誤り制御を変えると予想します。

   3. Start Up and Shut Down Procedures

3. 手順を立ち上げて、止めてください。

   We have not done enough thinking about the problem of the host which
   participates part-time in the network, which ceases normal network
   operation but remains on the network for special purposes, or which
   recovers from a system failure.  These issues are critical to robust
   network operation and are possibly our highest priority.  4. Query
   and Response

私たちは、ネットワークでパートタイムで参加しますが、通常のネットワーク操作をやめますが、特別な目的のためのネットワークに残っているか、またはシステム障害から回復するホストの問題について考えながら、十分していません。 これらの問題は、体力を要しているネットワーク操作に重要であり、ことによると私たちの最優先です。 4. 質問と応答

   A host-to-host status test would be a valuable tool, but it is not
   yet clear what is appropriate to provide.

ホストからホストへの状態テストは貴重なツールでしょうが、何が提供するのが適切であるかは、まだ明確ではありません。

Crocker, Postel, Newkirk & Kraley                              [Page 8]

RFC 54              An Official Protocol Proffering        18 June 1970

クロッカー、ポステル、ニューカーク、および1970年6月18日を提供する公式のプロトコルあたりKraley[8ページ]RFC54

Coming onto the Network

ネットワークに来ること。

   We suggest that hosts come onto the network gingerly.  First, each
   host should thoroughly exercise connections to itself.  Then it
   should arrange experiments with some other host who is already
   functioning.  Finally, it may begin to exercise the facilities of
   other hosts.  It is not clear at this time which host will be in the
   best position to help other hosts first, but UCLA will attempt to
   serve this function.

私たちは、ホストが非常に用心深くネットワークに来ることを提案します。 まず最初に、各ホストは接続をそれ自体に徹底的に運動させるべきです。 そして、それは既に機能しているある他のホストと共に実験をアレンジするべきです。 最終的に、それは他のホストの施設を運動させ始めるかもしれません。 どのホストが最初に他のホストを助ける最も良い立場にいるかが、このとき、明確ではありませんが、UCLAは、この機能を果たすのを試みるでしょう。

Private Networking

個人的なネットワーク

   A common ploy is to use the IMP to connect several local computers,
   one or more of which is not available to the whole network.  For
   example, Harvard is connecting its PDP-1 to its PDP-10 via an IMP;
   Lincoln Laboratories is connecting its TSP to the 360/67 and the TX2
   via an IMP; and UCLA is similarly connecting a XDS 920 to its Sigma-
   7.  In each of these cases, the small machine will not initially
   provide services to the network.

それの数台のローカルコンピュータを接続するIMP、1つまたは以上が全体のネットワークに利用可能でない使用には一般的な仕事があります。 例えば、ハーバードはIMPを通してPDP-1をPDP-10に接続しています。 リンカーン研究所はIMPを通して360/67とTX2にTSPを接続しています。 そして、UCLAは同様にXDS920をSigma7に接続しています。 それぞれのこれらの場合では、小さいマシンは初めは、ネットワークに対するサービスを提供しないでしょう。

   Although there should be no unwanted traffic to any of these extra
   hosts, it is desirable that they conform minimally to the network
   protocol.  Provided that they never initiate a connection or send out
   spurious control commands, it is sufficient for a host to respond to
   CLS commands with acknowledging CLS commands, and to respond to ECO
   commands with ERP commands.

これらの余分なホストのどれかへのどんな求められていない交通もあるべきではありませんが、彼らがネットワーク・プロトコルに最少量で従うのは、望ましいです。 彼らが接続を開始するか、または偽りの制御コマンドを決して出さなければ、ホストがCLSコマンドを承諾するのにCLSコマンドに反応して、ERPコマンドでECOコマンドに反応するために十分です。

Acknowledgments

承認

   The work presented above is only a small portion of the concurrent
   effort.  Most of the related effort will be reported in immediately
   forthcoming RFC's.  A number of people provided extremely valuable
   aid during the last two weeks.  We are particularly grateful to
   Professor George Mealy of Harvard for supporting four of his students
   to come westward to work on the network, to Robert Uzgalis for
   facilitating access to CCN at UCLA, and to the secretarial staff of
   the Computer Science Division of the University of Utah, and
   especially Peggy Tueller and Marcella Sanchez, for excellent help in
   preparing these documents.

上に提示された仕事は同時発生の努力の少量にすぎません。 Most of the related effort will be reported in immediately forthcoming RFC's. 多くの人々がここ2週間非常に貴重な援助を提供しました。 私たちは特に西向きにネットワークに対する仕事に来るために彼の4人の学生を支持してくださったことにハーバードのジョージMealy教授に感謝しています、UCLAのCCNと、そして、コンピュータユタ大学学術課の秘書課のスタッフへのアクセスを容易にするためのロバートUzgalis、特にペギーTueller、およびマルチェラ・サンチェスに、これらのドキュメントを準備することにおける素晴らしい助けのために。

       [ This RFC was put into machine readable form for entry ]
      [ into the online RFC archives by Eitetsu Baumgardner 3/97 ]

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

Crocker, Postel, Newkirk & Kraley                              [Page 9]

クロッカー、ポステル、ニューカーク、およびKraley[9ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ナインパッチとは(9-Patch)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る