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ページ]
一覧
スポンサーリンク