[要約] RFC 6529は、ARPAネットワークのためのホスト/ホストプロトコルに関する規格です。このRFCの目的は、ホスト間の通信を効率的かつ信頼性の高いものにするためのプロトコルを提供することです。
Independent Submission A. McKenzie
Request for Comments: 6529 S. Crocker
Category: Historic April 2012
ISSN: 2070-1721
Host/Host Protocol for the ARPA Network
ARPAネットワークのホスト/ホストプロトコル
Abstract
概要
This document reproduces the Host/Host Protocol developed by the ARPA Network Working Group during 1969, 1970, and 1971. It describes a protocol used to manage communication between processes residing on independent Hosts. It addresses issues of multiplexing multiple streams of communication (including addressing, flow control, connection establishment/disestablishment, and other signaling) over a single hardware interface. It was the official protocol of the ARPA Network from January 1972 until the switch to TCP/IP in January 1983. It is offered as an RFC at this late date to help complete the historical record available through the RFC series.
このドキュメントは、1969年、1970年、および1971年にARPAネットワークワーキンググループによって開発されたホスト/ホストプロトコルを再現しています。独立したホストに住むプロセス間のコミュニケーションを管理するために使用されるプロトコルについて説明しています。単一のハードウェアインターフェイスを介して、複数の通信ストリーム（アドレス指定、フロー制御、接続確立/不安定、その他のシグナル伝達を含む）を多重化する問題に対処します。1972年1月から1983年1月にTCP/IPへの切り替えまでのARPAネットワークの公式プロトコルでした。これは、RFCシリーズを通じて利用可能な歴史的記録を完了するのに役立つこの後期にRFCとして提供されます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントは、インターネット標準の追跡仕様ではありません。歴史的記録のために公開されています。
This document defines a Historic Document for the Internet community. This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティ向けの歴史的なドキュメントを定義しています。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6529.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6529で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. A Few Comments on Nomenclature and Key Concepts .................4
3. Host/Host Protocol Document .....................................5
(with its own table of contents on page 7)
4. Security Considerations ........................................34
The Host/Host Protocol for the ARPA Network was created during 1969, 1970, and 1971 by the Network Working Group, chaired by Steve Crocker, a graduate student at UCLA. Many of the RFCs with numbers less than 72, plus RFCs 102, 107, 111, 124, 132, 154, and 179 dealt with the development of this protocol. The first official document defining the protocol was issued by Crocker on August 3, 1970 as "Host-Host Protocol Document No. 1" (see citation in RFC 65), which was based on RFC 54 by Crocker, Postel, Newkirk, and Kraley. Revision of Document No. 1 began in mid-February 1971, as discussed in RFC 102. Although McKenzie is listed as the author of the January 1972 document, which superseded Document No. 1, it is more correct to say McKenzie was the person who compiled and edited the document. Most or all of the ideas in the document originated with others.
ARPAネットワークのホスト/ホストプロトコルは、1969年、1970年、1971年にUCLAの大学院生であるSteve Crockerが議長を務めるネットワークワーキンググループによって作成されました。数字が72未満のRFCの多くに加えて、RFCS 102、107、111、124、132、154、および179がこのプロトコルの開発に対処しました。プロトコルを定義する最初の公式文書は、1970年8月3日にCrockerによって「ホストホストプロトコルドキュメントNo.1」（RFC 65の引用を参照）として発行されました。。ドキュメントNo. 1の改訂は、RFC 102で説明したように1971年2月中旬に始まりました。マッケンジーは1972年1月のドキュメントの著者としてリストされていますが、ドキュメントNo. 1に取って代わったが、マッケンジーは人だったと言う方が正しいことです。ドキュメントを編集して編集しました。ドキュメント内のほとんどまたはすべてのアイデアは、他の人から生まれました。
At the time "Host-Host Protocol Document No. 1" was issued it was not given an RFC number because it was not to be viewed as a "request for comments" but as a standard for implementation. It was one of a set of such standards maintained as a separate set of documentation by the Network Information Center (NIC) at Stanford Research Institute (SRI). The January 1972 version (NIC 8246) reproduced here also followed that approach. It has been noted by many that all subsequent standards were issued as RFCs, and the absence of the Host/Host Protocol specification from the RFC series creates a curious gap in the historical record. It is to fill that gap that this RFC is offered.
「ホストホストプロトコルドキュメントNo.1」が発行されたとき、「コメントのリクエスト」と見なされるのではなく、実装の標準として見られるため、RFC番号は与えられませんでした。これは、スタンフォードリサーチインスティテュート（SRI）のネットワーク情報センター（NIC）によって別のドキュメントセットとして維持されているこのような標準のセットの1つでした。ここで再現された1972年1月バージョン（NIC 8246）もそのアプローチに従いました。多くの人が、その後のすべての基準がRFCとして発行されたことが指摘されており、RFCシリーズからホスト/ホストプロトコル仕様が存在しないと、歴史的記録に奇妙なギャップが生まれます。このRFCが提供されるのは、そのギャップを埋めることです。
In 1972, most ARPA Network documents, RFCs and others, were prepared and distributed in hard copy. The Host/Host Protocol document was typed on a typewriter (probably an IBM Selectric), which had interchangeable print elements, and used both italic and boldface fonts in addition to the regular font. Diagrams were drawn by a graphic artist and pasted into the typed document. Since RFCs are constrained to use a single typeface, we have tried to indicate boldface by the use of either all capitals or by a double underline, and to indicate italics by the use of underscores around words in place of spaces. The resulting document is a bit more difficult to read, but preserves the emphases of the original. Of course, the pagination has changed, and we hope we have correctly modified all of the page numbers. There were three footnotes in the original document and we have moved these into the text, set off by indentation and square brackets. A .pdf image of the original document can be found at http://www.cbi.umn.edu/hostedpublications/pdf/McKenzieNCP1972.pdf.
1972年、ほとんどのARPAネットワークドキュメント、RFCなどが準備され、ハードコピーで配布されました。ホスト/ホストプロトコルドキュメントは、互換性のある印刷要素を備えたタイプライター（おそらくIBM Selectric）に入力され、通常のフォントに加えて斜体と太字の両方のフォントを使用しました。図はグラフィックアーティストによって描かれ、型付き文書に貼り付けられました。 RFCは単一の書体を使用するように制約されているため、すべての首都または二重下線のいずれかを使用することで太字を示し、スペースの代わりに単語の周りのアンダースコアを使用して斜体を示すことを試みました。得られたドキュメントの読み取りはもう少し困難ですが、オリジナルの強調を保持します。もちろん、ページネーションは変わりました。すべてのページ番号を正しく変更したことを願っています。元のドキュメントには3つの脚注があり、これらをテキストに移動し、インデントと四角い括弧で引き立てました。元のドキュメントの.pdf画像は、http：//www.cbi.umn.edu/hostedpublications/pdf/mckenziencp1972.pdfにあります。
In the protocol definition, "RFC" is used to mean "Request for Connection", which refers to either a "Sender to Receiver" or a "Receiver to Sender" request to initiate a connection. In retrospect, this seems like an unnecessarily confusing choice of terminology.
プロトコルの定義では、「RFC」は「接続の要求」を意味するために使用されます。これは、「受信者への送信者」または「送信者から送信者への受信者」のいずれかを指し、接続を開始します。振り返ってみると、これは不必要に混乱する用語の選択のように思われます。
At the time this protocol was defined, it was given the undistinguished name "Host-Host Protocol." The acronym "NCP" meant "Network Control Program" and referred to the code that had to be added to the operating system within each host to enable it to interact with its Interface Message Processor (IMP) and manage multiple connections. Over time, and particularly in the context of the change from this protocol to TCP/IP, this protocol was commonly called "NCP" and the expansion changed to "Network Control Protocol."
このプロトコルが定義されたときに、「ホストホストプロトコル」という名前のない名前が与えられました。頭字語「NCP」は「ネットワーク制御プログラム」を意味し、各ホスト内のオペレーティングシステムに追加する必要があるコードを参照して、インターフェイスメッセージプロセッサ（IMP）と対話し、複数の接続を管理できるようにしました。時間が経つにつれて、特にこのプロトコルからTCP/IPへの変更のコンテキストでは、このプロトコルは一般に「NCP」と呼ばれ、拡張は「ネットワーク制御プロトコル」に変更されました。
This protocol was superseded by TCP. In this document, the protocol is referred to as a second layer (or "level") protocol, whereas in current writings TCP is usually referred to as a layer 4 protocol. When this protocol was created, it was expected that over time new layers would be created on top of, below, and even in between existing layers.
このプロトコルはTCPに取って代わられました。このドキュメントでは、プロトコルは2番目のレイヤー（または「レベル」）プロトコルと呼ばれますが、現在の執筆ではTCPは通常、レイヤー4プロトコルと呼ばれます。このプロトコルが作成されたとき、時間の経過とともに新しいレイヤーが既存のレイヤーの上部、下、さらにはさらに作成されることが予想されていました。
This protocol used a separate channel (the control link) to manage connections. This was abandoned in future protocols.
このプロトコルは、接続を管理するために別のチャネル（制御リンク）を使用しました。これは、将来のプロトコルで放棄されました。
In this design, there was no checksum or other form of error control except for the RST. There had been in earlier versions, but it was removed at the insistence of the IMP designers who argued vigorously that the underlying network of IMPs would never lose a packet or deliver one with errors. Although the IMP network was generally quite reliable, there were instances where the interface between the IMP and the host could drop bits, and, of course, experience with congestion control as the network was more heavily used made it clear that the host layer would have to deal with occasional losses in transmission. These changes were built into TCP.
この設計では、RSTを除き、チェックサムまたは他の形式のエラー制御はありませんでした。以前のバージョンにはありましたが、IMPの基礎となるネットワークがパケットを失うことやエラーのあるものを届けることは決してないと激しく主張したIMPデザイナーの主張で削除されました。IMPネットワークは一般的に非常に信頼性が高かったが、IMPとホストの間のインターフェースがビットを落とす可能性がある場合、そしてもちろん、ネットワークがより重く使用されているため、うっ血制御の経験により、ホスト層が持っていたことは明らかになった。伝送の時折の損失に対処するため。これらの変更はTCPに組み込まれています。
Uncertainty about timing constraints in the design of protocols is evident in this document and remains a source of ambiguity, limitation, and error in today's design processes.
プロトコルの設計におけるタイミングの制約に関する不確実性は、このドキュメントでは明らかであり、今日の設計プロセスのあいまいさ、制限、エラーの原因のままです。
Host/Host Protocol for the ARPA Network
ARPAネットワークのホスト/ホストプロトコル
Prepared for the Network Working Group by Alex McKenzie BBN January 1972
Alex McKenzie BBNによるネットワークワーキンググループの準備1972年1月
PREFACE
序文
This document specifies a protocol for use in communication between Host computers on the ARPA Network. In particular, it provides for connection of independent processes in different Hosts, control of the flow of data over established connections, and several ancillary functions. Although basically self-contained, this document specifies only one of several ARPA Network protocols; all protocol specifications are collected in the document _Current_Network_Protocols,_ NIC #7104.
このドキュメントは、ARPAネットワーク上のホストコンピューター間の通信で使用するプロトコルを指定します。特に、さまざまなホストでの独立したプロセスの接続、確立された接続上のデータの流れの制御、およびいくつかの補助機能を提供します。基本的に自己完結型ですが、このドキュメントは、いくつかのARPAネットワークプロトコルの1つのみを指定しています。すべてのプロトコル仕様は、ドキュメント_current_network_protocols、_ nic＃7104で収集されています。
This document supersedes NIC #7147 of the same title. Principal differences between the documents include:
このドキュメントは、同じタイトルのNIC＃7147に取って代わります。ドキュメント間の主な違いは次のとおりです。
- prohibition of spontaneous RET, ERP, and RRP commands - a discussion of the problem of unanswered CLS commands (page 16) - a discussion of the implications of queueing and not queueing RFCs (page 14) - the strong recommendation that received ERR commands be logged, and some additional ERR specifications.
- 自発的なRET、ERP、およびRRPコマンドの禁止 - 未回答のCLSコマンドの問題の議論（16ページ） - キューイングではなくキューイングの意味の議論（14ページ） - 誤差コマンドを受け取った強力な推奨事項は記録されます、およびいくつかの追加のERR仕様。
In addition to the above, several minor editorial changes have been made.
上記に加えて、いくつかの小さな編集上の変更が行われました。
Although there are many individuals associated with the network who are knowledgeable about protocol issues, individuals with questions pertaining to Network protocols should initially contact one of the following:
プロトコルの問題について知識があるネットワークに関連する多くの個人がいますが、ネットワークプロトコルに関連する質問を持つ個人は、最初に次のいずれかに連絡する必要があります。
Steve Crocker Advanced Research Projects Agency 1400 Wilson Boulevard Arlington, Virginia 22209 (202) 694-5921 or 5922
Steve Crocker Advanced Research Projects Agency 1400 Wilson Boulevard Arlington、Virginia 22209（202）694-5921または5922
Alex McKenzie Bolt Beranek and Newman Inc. 50 Moulton Street Cambridge, Massachusetts 02133 (617) 491-1350 ext. 441
Alex McKenzie Bolt Beranek and Newman Inc. 50 Moulton Street Cambridge、Massachusetts 02133（617）491-1350 Ext。441
Jon Postel University of California at Los Angeles Computer Science Department 3732 Boelter Hall Los Angeles, California 90024 (213) 325-2363
カリフォルニア州カリフォルニア大学コンピューターサイエンス部門3732ボルトルホールロサンゼルス、カリフォルニア州90024（213）325-2363
TABLE OF CONTENTS
目次
I. INTRODUCTION..................................................8
An overview of the multi-leveled protocol structure in the ARPA
Network.
II. COMMUNICATION CONCEPTS.......................................10
Definitions of terminology and a description of the overall
strategy used in Host-to-Host communication.
III. NCP FUNCTIONS................................................13
The meat of the document for the first-time reader. Host-to-
Host "commands" are introduced with descriptions of conditions
of their use, discussion of possible problems, and other
background material.
Connection Establishment..........................13
Connection Termination............................15
Flow Control......................................17
Interrupts........................................20
Test Inquiry......................................20
Reinitialization..................................21
IV. DECLARATIVE SPECIFICATIONS...................................23
Details for the NCP implementer. A few additional "commands"
are introduced, and those described in Section III are
reviewed. Formats and code and link assignments are specified.
Message Format....................................23
Link Assignment...................................25
Control Messages..................................25
Control Commands..................................25
Opcode Assignment.................................31
Control Command Summary...........................31
I. INTRODUCTION
I.はじめに
The ARPA Network provides a capability for geographically separated computers, called Hosts, to communicate with each other. The Host computers typically differ from one another in type, speed, word length, operating system, etc. Each Host computer is connected into the network through a local small computer called an _Interface_ _Message_Processor_(IMP)._ The complete network is formed by interconnecting these IMPs, all of which are virtually identical, through wideband communications lines supplied by the telephone company. Each IMP is programmed to store and forward messages to the neighboring IMPs in the network. During a typical operation, a Host passes a message to its local IMP; the first 32 bits of this message include the "network address" of a destination Host. The message is passed from IMP to IMP through the Network until it finally arrives at the destination IMP, which in turn passes it along to the destination Host.
ARPAネットワークは、ホストと呼ばれる地理的に分離されたコンピューターが相互に通信する機能を提供します。ホストコンピューターは通常、タイプ、速度、単語の長さ、オペレーティングシステムなどが互いに異なります。各ホストコンピューターは、_interface_ _message_processor_（IMP）と呼ばれるローカルの小さなコンピューターを介してネットワークに接続されます。_完全なネットワークは、相互接続によって形成されますこれらはすべて、電話会社が提供する広帯域通信ラインを通じて、事実上同一です。各IMPは、ネットワーク内の隣接するIMPにメッセージを保存および転送するようにプログラムされています。典型的な操作中に、ホストはそのローカルIMPにメッセージを渡します。このメッセージの最初の32ビットには、宛先ホストの「ネットワークアドレス」が含まれます。メッセージは、最終的に宛先IMPに到着するまで、ネットワークを介してIMPからIMPに渡され、宛先ホストに渡されます。
Specifications for the physical and logical message transfer between a Host and its local IMP are contained in Bolt Beranek and Newman (BBN) Report No. 1822. These specifications are generally called the _first_level_protocol_ or Host/IMP Protocol. This protocol is not by itself, however, sufficient to specify meaningful communication between processes running in two dissimilar Hosts. Rather, the processes must have some agreement as to the method of initiating communication, the interpretation of transmitted data, and so forth. Although it would be possible for such agreements to be reached by each pair of Hosts (or processes) interested in communication, a more general arrangement is desirable in order to minimize the amount of implementation necessary for Network-wide communication. Accordingly, the Host organizations formed a Network Working Group (NWG) to facilitate an exchange of ideas and to formulate additional specifications for Host-to-Host communications.
ホストとそのローカルIMPの間の物理的および論理的なメッセージ転送の仕様は、Bolt BeranekおよびNewman（BBN）レポートNo. 1822に含まれています。これらの仕様は、一般に_FIRST_LEVEL_PROTOCOL_またはHOST/IMPプロトコルと呼ばれます。ただし、このプロトコルはそれ自体ではありませんが、2つの異なるホストで実行されているプロセス間の意味のある通信を指定するのに十分です。むしろ、プロセスは、コミュニケーションを開始する方法、送信されたデータの解釈などについて何らかの合意を持っている必要があります。コミュニケーションに関心のあるホスト（またはプロセス）の各ペアがそのような契約に到達することは可能ですが、ネットワーク全体の通信に必要な実装の量を最小限に抑えるために、より一般的な取り決めが望ましいです。したがって、ホスト組織は、アイデアの交換を促進し、ホスト間通信のための追加の仕様を策定するために、ネットワークワーキンググループ（NWG）を形成しました。
The NWG has adopted a "layered" approach to the specification of communications protocol. The inner layer is the Host/IMP protocol. The next layer specifies methods of establishing communications paths, managing buffer space at each end of a communications path, and providing a method of "interrupting" a communications path. This protocol, which will be used by all higher-level protocols, is known as the _second_level_protocol,_ or Host/Host protocol. (It is worth noting that, although the IMP sub-network provides a capability for _message_switching,_ the Host/Host protocol is based on the concept of _line_switching._) Examples of further layers of protocol currently developed or anticipated include:
NWGは、通信プロトコルの仕様に「階層化された」アプローチを採用しています。内側の層は、ホスト/IMPプロトコルです。次のレイヤーは、通信パスを確立し、通信パスの両端でバッファースペースを管理し、通信パスを「中断」する方法を提供する方法を指定します。すべての高レベルプロトコルで使用されるこのプロトコルは、_Second_Level_Protocol、_またはホスト/ホストプロトコルとして知られています。（IMPサブネットワークは_message_switchingの機能を提供しますが、_ホスト/ホストプロトコルは_line_switching._の概念に基づいています）
1) An _Initial_Connection_Protocol_ (ICP) which provides a convenient standard method for several processes to gain simultaneous access to some specific process (such as the "logger") at another Host.
1) _initial_connection_protocol_（ICP）は、いくつかのプロセスに便利な標準メソッドを提供し、別のホストで特定のプロセス（「ロガー」など）に同時にアクセスできるようにします。
2) A _Telecommunication_Network_ (TELNET) protocol which provides for the "mapping" of an arbitrary keyboard-printer terminal into a Network Virtual Terminal (NVT), to facilitate communication between a terminal user at one Host site and a terminal-serving process at some other site which "expects" to be connected to a (local) terminal logically different from the (remote) terminal actually in use. The TELNET protocol specifies use of the ICP to establish the communication path between the terminal user and the terminal-service process.
2) _telecommunication_network_（telnet）プロトコルは、任意のキーボードプリンターターミナルのネットワーク仮想端末（NVT）への「マッピング」を提供し、1つのホストサイトでのターミナルユーザー間の通信と他のサイトでターミナルを使用するプロセスを促進します。これは、実際に使用されている（リモート）端子と論理的に異なる（ローカル）端末に「予想」されます。Telnetプロトコルは、ICPの使用を指定して、ターミナルユーザーとターミナルサービスプロセスの間の通信パスを確立します。
3) A _Data_Transfer_ protocol to specify standard methods of formatting data for shipment through the network.
3) ネットワークを介した出荷のフォーマットデータの標準的な方法を指定する_DATA_TRANSFER_プロトコル。
4) A _File_Transfer_ protocol to specify methods for reading, writing, and updating files stored at a remote Host. The File Transfer protocol specifies that the actual transmission of data should be performed in accordance with the Data Transfer protocol.
4) リモートホストに保存されているファイルを読み取り、書き込み、更新する方法を指定する_FILE_TRANSFER_プロトコル。ファイル転送プロトコルは、データ転送プロトコルに従ってデータの実際の伝送を実行する必要があることを指定します。
5) A _Graphics_ protocol to specify the means for exchanging graphics display information.
5) グラフィックスの表示情報を交換するための手段を指定する_graphics_プロトコル。
6) A _Remote_Job_Service_ (RJS) protocol to specify methods for submitting input to, obtaining output from, and exercising control over Hosts which provide batch processing facilities.
6) _REMOTE_JOB_SERVICE_（RJS）プロトコルは、バッチ処理施設を提供するホストの出力の取得、出力の取得、および行使のメソッドを指定します。
The remainder of this document describes and specifies the Host/Host, or second level, protocol as formulated by the Network Working Group.
このドキュメントの残りの部分では、ネットワークワーキンググループによって策定されたホスト/ホスト、または第2レベルのプロトコルについて説明および指定します。
II. COMMUNICATION CONCEPTS
ii。コミュニケーションの概念
The IMP sub-network imposes a number of physical restrictions on communications between Hosts; these restrictions are presented in BBN Report Number 1822. In particular, the concepts of leaders, messages, padding, links, and message types are of interest to the design of Host/Host protocol. The following discussion assumes that the reader is familiar with these concepts.
IMPサブネットワークは、ホスト間の通信に多くの物理的制限を課します。これらの制限は、BBNレポート番号1822に記載されています。特に、リーダー、メッセージ、パディング、リンク、およびメッセージタイプの概念は、ホスト/ホストプロトコルの設計に興味深いものです。以下の議論は、読者がこれらの概念に精通していることを前提としています。
Although there is little uniformity among the Hosts in either hardware or operating systems, the notion of multiprogramming dominates most of the systems. These Hosts can each concurrently support several users, with each user running one or more processes. Many of these processes may want to use the network concurrently, and thus a fundamental requirement of the Host/Host protocol is to provide for process-to-process communication over the network. Since the first level protocol only takes cognizance of Hosts, and since the several processes in execution within a Host are usually independent, it is necessary for the second level protocol to provide a richer addressing structure.
ハードウェアまたはオペレーティングシステムのいずれかのホスト間では均一性はほとんどありませんが、マルチプログラムの概念はほとんどのシステムを支配しています。これらのホストはそれぞれ複数のユーザーを同時にサポートでき、各ユーザーは1つ以上のプロセスを実行します。これらのプロセスの多くは、ネットワークを同時に使用したい場合があります。したがって、ホスト/ホストプロトコルの基本的な要件は、ネットワーク上のプロセス間通信を提供することです。最初のレベルのプロトコルはホストの認識のみを受け、ホスト内での実行中のいくつかのプロセスは通常独立しているため、第2レベルのプロトコルはより豊かなアドレス指定構造を提供する必要があります。
Another factor which influenced the Host/Host protocol design is the expectation that typical process-to-process communication will be based, not on a solitary message, but rather upon a sequence of messages. One example is the sending of a large body of information, such as a data base, from one process to another. Another example is an interactive conversation between two processes, with many exchanges.
ホスト/ホストのプロトコル設計に影響を与えたもう1つの要因は、典型的なプロセス間通信が孤独なメッセージではなく、一連のメッセージに基づいているという期待です。1つの例は、あるプロセスから別のプロセスにデータベースなどの多くの情報を送信することです。別の例は、2つのプロセス間のインタラクティブな会話であり、多くの交換があります。
These considerations led to the introduction of the notions of connections, a Network Control Program, a "control link", "control commands", connection byte size, message headers, and sockets.
これらの考慮事項は、接続の概念、ネットワーク制御プログラム、「コントロールリンク」、「コントロールコマンド」、接続バイトサイズ、メッセージヘッダー、ソケットの導入につながりました。
A _connection_ is an extension of a link. A connection couples two processes so that output from one process is input to the other. Connections are defined to be simplex (i.e., unidirectional), so two connections are necessary if a pair of processes are to converse in both directions.
_Connection_はリンクの拡張機能です。接続が2つのプロセスをカップルして、あるプロセスからの出力が他のプロセスに入力されるようにします。接続はシンプレックス（つまり、単方向）であると定義されるため、プロセスのペアが両方向に会話する場合、2つの接続が必要です。
Processes within a Host are envisioned as communicating with the rest of the network through a _Network_Control_Program_ (NCP), resident in that Host, which implements the second level protocol. The primary function of the NCP is to establish connections, break connections, and control data flow over the connections. We will describe the NCP as though it were part of the operating system of a Host supporting multiprogramming, although the actual method of implementing the NCP may be different in some Hosts.
ホスト内のプロセスは、第2レベルのプロトコルを実装するホストの居住者である_network_control_program_（ncp）を介してネットワークの他の部分と通信すると想定されています。NCPの主な機能は、接続を確立し、接続を破壊し、接続を介したデータフローを制御することです。NCPは、マルチプログラムをサポートするホストのオペレーティングシステムの一部であるかのように説明しますが、NCPを実装する実際の方法は一部のホストでは異なる場合があります。
In order to accomplish its tasks, the NCP of one Host must communicate with the NCPs of other Hosts. To this end, a particular link between each pair of Hosts has been designated as the _control_link._ Messages transmitted over the control link are called _control_messages_*, and must always be interpreted by an NCP as a sequence of one or more _control_commands_. For example, one kind of control command is used to initiate a connection, while another kind carries notification that a connection has been terminated.
タスクを達成するために、1つのホストのNCPは、他のホストのNCPと通信する必要があります。この目的のために、ホストの各ペア間の特定のリンクは、コントロールリンクを介して送信された_Control_Link._メッセージが_Control_Messages_*と呼ばれるために指定されており、常に1つ以上の_Control_Commands_のシーケンスとしてNCPによって解釈される必要があります。たとえば、1つの種類の制御コマンドが接続を開始するために使用されますが、別の種類には接続が終了したという通知が含まれます。
[*Note that in BBN Report Number 1822, messages of non-zero type are called control messages, and are used to control the flow of information between a Host and its IMP. In this document, the term "control message" is used for a message of type zero transmitted over the control link. The IMPs take no special notice of these messages.]
[*BBNレポート番号1822では、ゼロ以外のタイプのメッセージはコントロールメッセージと呼ばれ、ホストとそのIMP間の情報の流れを制御するために使用されることに注意してください。このドキュメントでは、「コントロールメッセージ」という用語は、コントロールリンクを介して送信されたタイプゼロのメッセージに使用されます。IMPはこれらのメッセージを特別な通知しません。]
The concept of a message, as used above, is an artifact of the IMP sub-network; network message boundaries may have little intrinsic meaning to communicating processes. Accordingly, it has been decided that the NCP (rather than each transmitting process) should be responsible for segmenting interprocess communication into network messages. Therefore, it is a principal of the second level protocol that no significance may be inferred from message boundaries by a receiving process. _The_only_exception_to_this_principle_is_in_ _control_messages,_each_of_which_must_contain_an_integral_number_of_ _control_commands._
上記で使用したメッセージの概念は、IMPサブネットワークのアーティファクトです。ネットワークメッセージの境界は、プロセスを通信するための本質的な意味がほとんどない場合があります。したがって、NCP（各送信プロセスではなく）が、インタープロセス通信をネットワークメッセージにセグメント化する責任があることが決定されています。したがって、受信プロセスによってメッセージの境界から有意性が推測されないことは、第2レベルのプロトコルのプリンシパルです。_the_only_exception_to_this_principle_is_in_ _control_messages、_each_of_which_must_contain_an_integral_number_of_ _control_commands._
Since message boundaries are selected by the transmitting NCP, the receiving NCP must be prepared to concatenate successive messages from the network into a single (or differently divided) transmission for delivery to the receiving process. The fact that Hosts have different word sizes means that a message from the network might end in the middle of a word at the receiving end, and thus the concatenation of the next message might require the receiving Host to carry out extensive bit-shifting. Because bit-shifting is typically very costly in terms of computer processing time, the protocol includes the notions of connection byte size and message headers.
メッセージの境界は送信NCPによって選択されるため、受信NCPは、ネットワークから連続したメッセージを単一の（または異なる分割）送信を受信プロセスに連結する準備をする必要があります。ホストが異なる単語サイズを持っているという事実は、ネットワークからのメッセージが受信側の単語の途中で終了する可能性があることを意味します。ビットシフトは通常、コンピューター処理時間の点で非常にコストがかかるため、プロトコルには接続バイトサイズとメッセージヘッダーの概念が含まれます。
As part of the process of establishing a connection, the processes involved must agree on a _connection_byte_size._ Each message sent over the connection must then contain an integral number of bytes of this size. Thus the pair of processes involved in a connection can choose a mutually convenient byte size, for example, the least common multiple of their Host word lengths. It is important to note that the ability to choose a byte size _must_ be available to the processes involved in the connection; an NCP is prohibited from imposing an arbitrary byte size on any process running in its own
接続を確立するプロセスの一部として、関係するプロセスは_connection_byte_size._に同意する必要があります。したがって、接続に関与するプロセスのペアは、相互に便利なバイトサイズ、たとえばホストワードの長さの中で最も一般的な倍数を選択できます。接続に関与するプロセスでバイトサイズ_MUST_を選択できることに注意することが重要です。NCPは、独自に実行されているプロセスに任意のバイトサイズを課すことを禁止されています
Host. In particular, an outer layer of protocol may specify a byte size to be used by that protocol. If some NCP is unable to handle that byte size, then the outer layer of protocol will not be implementable on that Host.
ホスト。特に、プロトコルの外層は、そのプロトコルで使用するバイトサイズを指定する場合があります。一部のNCPがそのバイトサイズを処理できない場合、プロトコルの外層はそのホストに実装できません。
The IMP sub-network requires that the first 32 bits of each message (called the leader) contain addressing information, including destination Host address and link number. The second level protocol extends the required information at the beginning of each message to a total of 72 bits; these 72 bits are called the _message_header._ A length of 72 bits is chosen since most Hosts either can work conveniently with 8-bit units of data or have word lengths of 18 or 36 bits; 72 is the least common multiple of these lengths. Thus, the length chosen for the message header should reduce bit-shifting problems for many Hosts. In addition to the leader, the message header includes a field giving the byte size used in the message, a field giving the number of bytes in the message, and "filler" fields. The format of the message header is fully described in Section IV.
IMPサブネットワークでは、各メッセージの最初の32ビット（リーダーと呼ばれる）には、宛先ホストアドレスやリンク番号を含むアドレス指定情報が含まれています。第2レベルのプロトコルは、各メッセージの先頭に必要な情報を合計72ビットに拡張します。これらの72ビットは_message_header._と呼ばれます。_ほとんどのホストは8ビット単位のデータで便利に動作するか、18または36ビットの単語の長さを持つことができるため、72ビットの長さが選択されます。72は、これらの長さの中で最も一般的ではない倍数です。したがって、メッセージヘッダーに選択された長さは、多くのホストのビットシフトの問題を減らす必要があります。リーダーに加えて、メッセージヘッダーには、メッセージで使用されるバイトサイズを与えるフィールド、メッセージ内のバイト数を与えるフィールド、および「フィラー」フィールドが含まれます。メッセージヘッダーの形式は、セクションIVで完全に説明されています。
Another major concern of the second level protocol is a method for reference to processes in other Hosts. Each Host has some internal scheme for naming processes, but these various schemes are typically different and may even be incompatible. Since it is not practical to impose a common internal process naming scheme, a standard intermediate name space is used, with a separate portion of the name space allocated to each Host. Each Host must have the ability to map internal process identifiers into its portion of this name space.
第2レベルのプロトコルのもう1つの主要な懸念は、他のホストのプロセスを参照する方法です。各ホストには命名プロセスのための内部スキームがありますが、これらのさまざまなスキームは通常異なり、互換性がない場合もあります。共通の内部プロセス命名スキームを課すことは実用的ではないため、各ホストに割り当てられる名前スペースの別の部分を持つ標準的な中間名スペースが使用されます。各ホストには、内部プロセス識別子をこの名前空間の部分にマッピングする機能が必要です。
The elements of the name space are called _sockets._ A socket forms one end of a connection, and a connection is fully specified by a pair of sockets. A socket is identified by a Host number and a 32-bit socket number. The same 32-bit number in different Hosts represents different sockets.
名前空間の要素は_sockets._ソケットが接続の一端を形成し、接続がソケットのペアによって完全に指定されています。ソケットは、ホスト番号と32ビットソケット番号によって識別されます。異なるホストで同じ32ビット数は異なるソケットを表します。
A socket is either a _receive_socket_ or a _send_socket,_ and is so marked by its low-order bit (0 = receive; 1 = send). This property is called the socket's _gender._ The sockets at either end of a connection must be of opposite gender. Except for the gender, second level protocol places no constraints on the assignment of socket numbers within a Host.
ソケットは、_receive_socket_または_send_socket _のいずれかであり、その低次のビット（0 =受信; 1 = send）によって非常にマークされています。このプロパティは、ソケットの_gender._と呼ばれます。_接続の両端にあるソケットは、反対の性別でなければなりません。性別を除き、第2レベルのプロトコルは、ホスト内のソケット番号の割り当てに制約を課さない。
III. NCP FUNCTIONS
iii。NCP関数
The functions of the NCP are to establish connections, terminate connections, control flow, transmit interrupts, and respond to test inquiries. These functions are explained in this section, and control commands are introduced as needed. In Section IV the formats of all control commands are presented together.
NCPの機能は、接続を確立し、接続を終了し、制御フローを終了し、割り込みを送信し、テストの問い合わせに応答することです。これらの関数はこのセクションで説明されており、必要に応じてコントロールコマンドを紹介します。セクションIVでは、すべての制御コマンドの形式が一緒に表示されます。
Connection Establishment
========================
The commands used to establish a connection are STR (sender-to-receiver) and RTS (receiver- to-sender).
接続を確立するために使用されるコマンドは、STR（Sender-to-Receiver）およびRTS（受信者からセンダー）です。
8* 32 32 8
+----------------------------------------------+
| STR | send socket | receive socket | size |
+----------------------------------------------+
[*The number shown above each control command field is the length of that field in bits.]
[*各コントロールコマンドフィールドに示されている数値は、ビットのそのフィールドの長さです。]
8 32 32 8
+----------------------------------------------+
| RTS | receive socket | send socket | link |
+----------------------------------------------+
The STR command is sent from a prospective sender to a prospective receiver, and the RTS from a prospective receiver to a prospective sender. The send socket field names a socket local to the prospective sender; the receive socket field names a socket local to the prospective receiver. In the STR command, the "size" field contains an unsigned binary number (in the range 1 to 255; zero is prohibited) specifying the byte size to be used for all messages over the connection. In the RTS command, the "link" field specifies a link number; all messages over the connection must be sent over the link specified by this number. These two commands are referred to as requests-for-connection (RFCs). An STR and an RTS match if the receive socket fields match and the send socket fields match. A connection is established when a matching pair of RFCs have been exchanged. _Hosts_are_prohibited_from_establishing_more_than_one_ _connection_to_any_local_socket._
STRコマンドは、将来の送信者から将来の受信者に送信され、RTは見込み客から将来の送信者に送信されます。Send Socket Fieldは、見込み送信者にローカルのソケットに名前を付けます。受信ソケットフィールドには、見込み客のソケットに名前が付けられています。STRコマンドでは、「サイズ」フィールドには、接続上のすべてのメッセージに使用されるバイトサイズを指定する符号なしのバイナリ数（範囲1〜255;ゼロは禁止されています）が含まれています。RTSコマンドでは、「リンク」フィールドがリンク番号を指定します。接続を介したすべてのメッセージは、この番号で指定されたリンクを介して送信する必要があります。これらの2つのコマンドは、リクエストと接続（RFCS）と呼ばれます。受信ソケットフィールドとSend Socketフィールドが一致する場合、STRとRTSが一致します。一致するRFCのペアが交換されたときに接続が確立されます。_HOSTS_ARE_PROIBITED_FROM_ESTABLISHING_MORE_THAN_ONE_ _Connection_to_any_local_socket._
With respect to a particular connection, the Host containing the send socket is called the _sending_Host_ and the Host containing the receive socket is called the _receiving_Host._ A Host may connect one of its receive sockets to one of its send sockets, thus becoming both the sending Host and the receiving Host for that connection.
特定の接続に関して、送信ソケットを含むホストは_sending_host_と呼ばれ、受信ソケットを含むホストは_receiving_host._と呼ばれます。ホストは受信ソケットの1つを送信ソケットの1つに接続することができます。その接続のホストと受信ホストを送信します。
These terms apply only to data flow; control messages will, in general, be transmitted in both directions.
これらの用語は、データフローにのみ適用されます。一般に、コントロールメッセージは両方向に送信されます。
A Host sends an RFC either to request a connection, or to accept a foreign Host's request. Since RFC commands are used both for requesting and for accepting the establishment of a connection, it is possible for either of two cooperating processes to initiate connection establishment. As a consequence, a family of processes may be created with connection-initiating actions built-in, and the processes within this family may be started up (in different Hosts) in arbitrary order provided that appropriate queueing is performed by the Hosts involved (see below).
ホストは、接続を要求するか、外国人ホストの要求を受け入れるためにRFCを送信します。RFCコマンドは、接続の確立を要求し、受け入れるために使用されるため、2つの協力プロセスのいずれかが接続確立を開始することが可能です。結果として、接続開始アクションが組み込まれているプロセスファミリーを作成することができ、このファミリ内のプロセスは、関係するホストによって適切なキューイングが実行されると、任意の順序で（異なるホストで）起動することができます（参照下）。
_There_is_no_prescribed_lifetime_for_an_RFC._ A Host is permitted to queue incoming RFCs and withhold a response for an arbitrarily long time, or, alternatively, to reject requests (see Connection Termination below) immediately if it does not have a matching RFC outstanding. It may be reasonable, for example, for an NCP to queue an RFC that refers to some currently unused socket until a local process takes control of that socket number and tells the NCP to accept or reject the request. Of course, the Host which sent the RFC may be unwilling to wait for an arbitrarily long time, so it may abort the request. On the other hand, some NCP implementations may not include any space for queueing RFCs, and thus can be expected to reject RFCs unless the RFC sequence was initiated locally.
_THERE_IS_NO_PRESCRIBED_LIFETIME_FOR_AN_RFC._ホストは、RFCを任意に長時間締め出し、任意の長い時間の応答を差し控えることが許可されています。たとえば、NCPがローカルプロセスがそのソケット番号を制御し、NCPにリクエストを受け入れるか拒否するように指示するまで、現在使用されていないソケットを指すRFCをキューにキューすることが合理的かもしれません。もちろん、RFCを送信したホストは、任意の長い時間を待つことを嫌がる可能性があるため、リクエストを中止する可能性があります。一方、一部のNCP実装には、RFCをキューにするためのスペースが含まれていない場合があるため、RFCシーケンスがローカルで開始されない限り、RFCを拒否することが期待できます。
_Queueing_Considerations_
_queueing_considerations_
The decision to queue, or not queue, incoming RFCs has important implications which NCP implementers must not ignore. Each RFC which is queued, of course, requires a small amount of memory in the Host doing the queueing. If each incoming RFC is queued until a local process seizes the local socket and accepts (or rejects) the RFC, but no local process ever seizes the socket, the RFC must be queued "forever." Theoretically this could occur infinitely many times (there is no reason not to queue several RFCs for a single local socket, letting the local process decide which, if any, to accept) thus requiring infinite storage for the RFC queue. On the other hand, if no queueing is performed the cooperating processes described above will be able to establish a desired connection only by accident (when they are started up such that one issues its RFC while the RFC of the other is in transit in the network -- clearly an unlikely occurrence).
キューをキューにするかどうかの決定は、NCP実装者が無視してはならない重要な意味を持っています。もちろん、キューに登録されている各RFCには、ホストにキューイングを行う少量のメモリが必要です。ローカルプロセスがローカルソケットを押収してRFCを受け入れる（または拒否）するまで、各着信RFCがキューにキューになっているが、ローカルプロセスがソケットを押収することはない場合、RFCは「永遠に」キューに入れる必要があります。理論的には、これは無限に何度も発生する可能性があります（単一のローカルソケットのいくつかのRFCをキューにしない理由はありません。ローカルプロセスは、どの場合、どの場合、受け入れるかを決定します）したがって、RFCキューに無限のストレージが必要です。一方、キューイングが実行されない場合、上記の協力プロセスは、偶然にのみ目的の接続を確立できます（1つのRFCがネットワーク内で輸送中にRFCを発行するように起動した場合 - 明らかにありそうもない出来事）。
Perhaps the most reasonable solution to the problems posed above is for _each_ NCP to give processes running in its own Host two options for attempting to initiate connections. The first option would allow a process to cause an RFC to be sent to a specified remote socket;
おそらく、上記の問題に対する最も合理的な解決策は、_each_NCPが接続を開始しようとする2つのオプションを独自のホストで実行するプロセスを提供することです。最初のオプションにより、プロセスが指定されたリモートソケットにRFCを送信するようになります。
with the NCP notifying the process as to whether the RFC were accepted or rejected by the remote Host. The second option would allow a process to tell _its_own_ NCP to "listen" for an RFC to a specified local socket from some remote socket (the process might also specify the particular remote socket and/or Host it wishes to communicate with) and to accept the RFC (i.e., return a matching RFC) if and when it arrives. Note that this also involves queueing (of "listen" requests), but it is internal queueing which is susceptible to reasonable management by the local Host. If this implementation were available, one of two cooperating processes could "listen" while the other process caused a series of RFCs to be sent to the "listening" socket until one was accepted. Thus, no queueing of incoming RFCs would be required, although it would do no harm.
NCPは、RFCがリモートホストによって受け入れられたか拒否されたかについてのプロセスを通知します。2番目のオプションでは、プロセスが_its_own_ ncpにRFCを「聞く」ように指定して、リモートソケットから指定されたローカルソケットに「聞く」ことができます（プロセスは、特定のリモートソケットを指定したり、通信したいホストをホストしたりする可能性があります）RFC（つまり、一致するRFCを返します）が到着した場合。これには（「聞く」リクエストの）キューイングも含まれますが、それは地元のホストによる合理的な管理の影響を受けやすい内部キューイングであることに注意してください。この実装が利用可能な場合、2つの協力プロセスの1つが「聞く」ことができ、もう1つのプロセスにより、一連のRFCが「リスニング」ソケットに送信されました。したがって、害はありませんが、着信RFCのキューイングは必要ありません。
_It_is_the_intent_of_the_protocol_that_each_NCP_should_provide_ _either_the_"listen"_option_described_above_or_a_SUBSTANTIAL_ _queueing_facility._ This is not, however, an absolute requirement of the protocol.
_it_is_the_intent_of_the_protocol_that_each_ncp_should_provide_ _either_the_ "risten" _option_described_above_or_a_substantial_ _ queueing_facility._
Connection Termination
======================
The command used to terminate a connection is CLS (close).
接続を終了するために使用されるコマンドはCLS（近接）です。
8 32 32
+-----+-------------+-------------+
| CLS | my socket | your socket |
+-----+-------------+-------------+
The "my socket" field contains the socket local to the sender of the CLS command. The "your socket" field contains the socket local to the receiver of the CLS command. _Each_side_must_send_and_receive_a_ _CLS_command_before_connection_termination_is_completed_and_the_ _sockets_are_free_to_participate_in_other_connections._
「My Socket」フィールドには、CLSコマンドの送信者のソケットが含まれています。「Your Socket」フィールドには、CLSコマンドのレシーバーにローカルにローカルソケットが含まれています。_each_side_must_send_and_receive_a_ _cls_command_before_connection_termination_is_completed_and_the_ _sockets_are_free_to_partipate_in_other_connections._
It is not necessary for a connection to be established (i.e., for _both_ RFCs to be exchanged) before connection termination begins. For example, if a Host wishes to refuse a request for connection, it sends back a CLS instead of a matching RFC. The refusing Host then waits for the initiating Host to acknowledge the refusal by returning a CLS. Similarly, if a Host wishes to abort its outstanding request for a connection, it sends a CLS command. The foreign Host is obliged to acknowledge the CLS with its own CLS. Note that even though the connection was never established, CLS commands must be exchanged before the sockets are free for other use.
接続終了が開始される前に、接続を確立する必要はありません（つまり、_oth_ rfcsを交換する）。たとえば、ホストが接続のリクエストを拒否したい場合、一致するRFCの代わりにCLSを送り返します。その後、拒否ホストは、開始ホストがCLSを返すことで拒否を認めるのを待ちます。同様に、ホストが接続の未解決のリクエストを中止したい場合、CLSコマンドを送信します。外国人ホストは、独自のCLSでCLSを認める義務があります。接続が確立されていない場合でも、Socketsが他の使用のために無料である前にCLSコマンドを交換する必要があることに注意してください。
After a connection is established, CLS commands sent by the receiver
接続が確立された後、CLSコマンドは受信機によって送信されました
and sender have slightly different effects. CLS commands 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._ A CLS command sent by the receiver acts as a demand on the sender to terminate transmission. However, since there is a delay in getting the CLS command to the sender, the receiver must expect more input.
そして、送信者はわずかに異なる効果を持っています。送信者によって送信されたCLSコマンドは、接続を介してこれ以上メッセージが送信されないことを示します。_tis_command_must_not_be_sent_if_there_is_a_message_ _in_transit_over_the_connection._受信者によって送信されたCLSコマンドは、送信を終了するための送信者の要求として機能します。ただし、CLSコマンドを送信者に取得するのは遅れているため、受信者はより多くの入力を期待する必要があります。
A Host should "quickly" acknowledge an incoming CLS so the foreign Host can purge its tables. However, _there_is_no_prescribed_time_ _period_in_which_a_CLS_must_be_acknowledged._
ホストは、外国のホストがテーブルをパージできるように、入ってくるCLSを「迅速に」認める必要があります。ただし、_there_is_no_prescribed_time__period_in_which_a_cls_must_be_acknowledged._
Because the CLS command is used both to initiate closing, aborting and refusing a connection, and to acknowledge closing, aborting and refusing a connection, race conditions can occur. However, they do not lead to ambiguous or erroneous results, as illustrated in the following examples.
CLSコマンドは、接続を開始、接続の中止、拒否の両方に使用し、接続の閉鎖、中止、拒否の両方を使用するため、人種条件が発生する可能性があります。ただし、次の例に示すように、それらは曖昧または誤った結果につながりません。
EXAMPLE 1: Suppose that Host A sends Host B a request for connection, and then A sends a CLS to Host B because it is tired of waiting for a reply. However, just when A sends its CLS to B, B sends a CLS to A to refuse the connection. A will "believe" B is acknowledging the abort, and B will "believe" A is acknowledging its refusal, but the outcome will be correct.
例1：ホストAがホストBを接続の要求を送信し、A aは返信を待つのにうんざりしているため、ホストBにCLSを送信します。ただし、AがCLSをBに送信すると、BはCLSをAに送信して接続を拒否します。Aは「信じる」Bは中止を認めており、Bは「Aがその拒否を認めている」と「信じている」と思うが、結果は正しいだろう。
EXAMPLE 2: Suppose that Host A sends Host B an RFC followed by a CLS as in example 1. In this case, however, B sends a matching RFC to A just when A sends its CLS. Host A may "believe" that the RFC is an attempt (on the part of B) to establish a new connection or may understand the race condition; in either case it can discard the RFC since its socket is not yet free. Host B will "believe" that the CLS is breaking an _established_ connection, but the outcome is correct since a matching CLS is the required response, and both A and B will then terminate the connection.
例2：ホストAがホストBを送信し、例1のようにCLSを送信したと仮定します。ただし、この場合、Bは、AがCLSを送信したときにAに一致するRFCを送信します。ホストAは、RFCが新しい接続を確立するための試み（Bの側）であることを「信じる」ことができる、または人種の状態を理解することができるかもしれない。どちらの場合でも、ソケットがまだ無料ではないため、RFCを破棄できます。ホストBは、CLSが_ESTABLISHED_接続を破壊していることを「信じ」ますが、一致するCLSが必要な応答であり、AとBの両方が接続を終了するため、結果は正しいです。
Every NCP implementation is faced with the problem of what to do if a matching CLS is not returned "quickly" by a foreign Host (i.e., if the foreign Host appears to be violating protocol in this respect). One naive answer is to hold the connection in a partially closed state "forever" waiting for a matching CLS. There are two difficulties with this solution. First, the socket involved may be a "scarce resource" such as the "logger" socket specified by an Initial Connection Protocol (see NIC # 7101) which the local Host cannot afford to tie up indefinitely. Second, a partially broken (or malicious) process in a foreign Host may send an unending stream of RFCs which the local Host wishes to refuse by sending CLS commands and waiting for a match. This could, in worst cases, require 2^32 ! socket pairs to be stored before duplicates began to appear.
すべてのNCP実装は、一致するCLSが外国のホストによって「迅速に」返されない場合（つまり、外国人ホストがこの点でプロトコルに違反しているように見える場合）、何をすべきかという問題に直面しています。素朴な答えの1つは、接続を部分的に閉じた状態で「永遠に」照合するCLSを待っていることです。このソリューションには2つの困難があります。まず、関与するソケットは、ローカルホストが無期限に縛る余裕がない初期接続プロトコル（NIC＃7101を参照）で指定された「ロガー」ソケットなどの「希少なリソース」である場合があります。第二に、外国人ホストの部分的に壊れた（または悪意のある）プロセスは、地元のホストがCLSコマンドを送信して試合を待つことで拒否したいRFCの終わりのないストリームを送信する場合があります。これは、最悪の場合、2^32を必要とする可能性があります！重複が表示される前に保存されるソケットペア。
Clearly, no Host is prepared to store (or search) this much information.
明らかに、この多くの情報を保存（または検索）するホストは準備されていません。
A second possibility sometimes suggested is for the Host which is waiting for matching CLS commands (Host A) to send a RST (see page 20) to the offending Host (Host B), thus allowing all tables to be reinitialized at both ends. This would be rather unsatisfactory to any user at Host A who happened to be performing useful work on Host B via network connections, since these connections would also be broken by the RST.
2番目に提案される可能性は、CLSコマンド（ホストA）を一致させるのを待っているホスト（20ページを参照）を問題のあるホスト（ホストB）に送信するため、すべてのテーブルを両端で再活性化することができます。これは、これらの接続もRSTによって破壊されるため、ホストAのユーザーAのユーザーにとってはかなり不十分です。
Most implementers, recognizing these problems, have adopted some unofficial timeout period after which they "forget" a connection even if a matching CLS has not been received. The danger with such an arrangement is that if a second connection between the same pair of sockets is later established, and a CLS finally arrives for the first connection, the second connection is likely to be closed. This situation can only arise, however, if one Host violates protocol in two ways; first by failing to respond quickly to an incoming CLS, and second by permitting establishment of a connection involving a socket which it believes is already in use. It has been suggested that the network adopt some standard timeout period, but the NWG has been unable to arrive at a period which is both short enough to be useful and long enough to be acceptable to every Host. Timeout periods in current use seem to range between approximately one minute and approximately five minutes. _It_must_be_emphasized_that_all_timeout_ _periods,_although_they_are_relatively_common,_reasonably_safe,_and_ _quite_useful,_are_in_violation_of_the_protocol_since_their_use_can_ _lead_to_connection_ambiguities._
これらの問題を認識しているほとんどの実装者は、一致するCLSが受信されていなくても、接続を「忘れる」ため、非公式のタイムアウト期間を採用しています。このような配置の危険性は、同じソケットのペア間の2番目の接続が後で確立され、CLSが最終的に最初の接続に到着すると、2番目の接続が閉じられる可能性が高いことです。ただし、この状況は、1人のホストが2つの方法でプロトコルに違反した場合にのみ発生します。 1つ目は、着信CLSに迅速に応答しないことと、2つ目は、すでに使用されていると考えているソケットを含む接続の確立を許可することにより。ネットワークは標準のタイムアウト期間を採用することが示唆されていますが、NWGは、すべてのホストに受け入れられるほど便利で十分に長い間、両方とも十分に短い期間に到達することができませんでした。現在の使用のタイムアウト期間は、約1分から約5分の範囲の範囲であるように見えます。 _it_must_be_emphasized_that_all_timeout_ _periods、_ althey_are_relelinate_common、_ reasoinable_safe、_and_ _quite_useful、_are_in_violation_of_of_of_the_protocol_ins_their_useir_use_use_use_use_ccnexe_cnexe_cnexe_cnexe_cnexe_conex
Flow Control
============
After a connection is established, the sending Host sends messages over the agreed-upon link to the receiving Host. The receiving NCP accepts messages from its IMP and queues them for its various processes. Since it may happen that the messages arrive faster than they can be processed, some mechanism is required which permits the receiving Host to quench the flow from the sending Host.
接続が確立された後、送信ホストは、受信ホストへの合意されたリンクを介してメッセージを送信します。受信NCPは、IMPからのメッセージを受け入れ、さまざまなプロセスに対してキューをキューにします。メッセージが処理できるよりも速く到着することが起こる可能性があるため、受信ホストが送信ホストからのフローを消すことができるメカニズムが必要です。
The flow control mechanism requires the receiving Host to allocate buffer space for each connection and to notify the sending Host of how much space is available. The sending Host keeps track of how much room is available and never sends more data than it believes the receiving Host can accept.
フロー制御メカニズムでは、受信ホストが各接続にバッファースペースを割り当て、送信ホストに利用可能なスペースの量を通知する必要があります。送信ホストは、利用可能な部屋の量を追跡し、受信ホストが受け入れることができると考えているよりも多くのデータを送信することはありません。
To implement this mechanism, the sending Host keeps two counters
このメカニズムを実装するために、送信ホストは2つのカウンターを保持します
associated with each connection, a _message_counter_ and a _bit_counter._ Each counter is initialized to zero when the connection is established and is increased by allocate (ALL) control commands sent from the receiving Host as described below. When sending a message, the NCP of the sending Host subtracts one from the message counter and the _text_length_ (defined below) from the bit counter. The sender is prohibited from sending if either counter would be decremented below zero. The sending Host may also return all or part of the message or bit space allocation with a return (RET) command upon receiving a give-back (GVB) command from the receiving Host (see below).
各接続に関連付けられている、_message_counter_および_bit_counter._各カウンターは、接続が確立されたときにゼロに初期化され、以下に説明するように受信ホストから送信された（すべて）制御コマンドによって増加します。メッセージを送信すると、送信ホストのNCPは、メッセージカウンターから1つとビットカウンターから_text_length_（以下に定義されています）を差し引きます。どちらかのカウンターがゼロ以下で減少する場合、送信者は送信を禁止されます。送信ホストは、受信ホストからGive-Back（GVB）コマンドを受信したときに、RETURN（RET）コマンドでメッセージまたはビットスペース割り当てのすべてまたはBITスペース割り当てを返すこともできます（以下を参照）。
The _text_length_ of a message is defined as the product of the connection byte size and the byte count for the message; both of these quantities appear in the message header. Messages with a zero byte count, hence a zero text length, are specifically permitted. Messages with zero text length do not use bit space allocation, but do use message space allocation. The flow control mechanisms do not pertain to the control link, since connections are never explicitly established over this link.
メッセージの_text_length_は、メッセージの接続バイトサイズの積とメッセージのバイトカウントとして定義されます。これらの数量は両方ともメッセージヘッダーに表示されます。バイトカウントがゼロ、したがってゼロのテキスト長を持つメッセージは、特に許可されています。テキストの長さがゼロのメッセージは、ビットスペース割り当てを使用しませんが、メッセージスペース割り当てを使用します。このリンクを介して接続が明示的に確立されることは決してないため、フロー制御メカニズムは制御リンクに関係しません。
The control command used to increase the sender's bit counter and message counter is ALL (allocate).
送信者のビットカウンターとメッセージカウンターを増やすために使用されるコントロールコマンドはすべて（割り当て）です。
8 8 16 32
+------------------------------------+
| ALL | link | msg space | bit space |
+------------------------------------+
This command is sent only from the receiving Host to the sending Host, and is legal only when a connection using the link number appearing in the "link" field is established. The "msg space" field and the "bit space" field are defined to be unsigned binary integers specifying the amounts by which the sender's message counter and bit counter (respectively) are to be incremented. The receiver is prohibited from incrementing the sender's counter above (2^16 - 1), or the sender's bit counter above (2^32 - 1). In general, this rule will require the receiver to maintain counters which are incremented and decremented according to the same rules as the sender's counters.
このコマンドは、受信ホストから送信ホストにのみ送信され、「リンク」フィールドに表示されるリンク番号を使用した接続が確立された場合にのみ合法です。「MSGスペース」フィールドと「ビットスペース」フィールドは、送信者のメッセージカウンターとビットカウンターがそれぞれ（それぞれ）増加する量を指定する署名されていないバイナリ整数であると定義されます。受信者は、上記の送信者のカウンター（2^16-1）または上記の送信者のビットカウンター（2^32-1）を増加させることを禁止されています。一般に、このルールでは、受信者が送信者のカウンターと同じルールに従って増加および減少するカウンターを維持する必要があります。
The receiving Host may request that the sending Host return all or part of its current allocation. The control command for this request is GVB (give-back).
受信ホストは、送信ホストが現在の割り当てのすべてまたは一部を返すように要求する場合があります。このリクエストの制御コマンドはGVB（Give-Back）です。
8 8 8 8
+----------------------+
| GVB | link | fm | fb |
+----------------------+
This command is sent only from the receiving Host to the sending Host, and is legal only when a connection using the link number in the "link" field is established. The fields fm and fb are defined as the fraction (in 128ths) of the current message space allocation and bit space allocation (respectively) to be returned. If either of the fractions is equal to or greater than one, _all_ of the corresponding allocation must be returned. Fractions are used since, with messages in transit, the sender and receiver may not agree on the actual allocation at every point in time.
このコマンドは、受信ホストから送信ホストにのみ送信され、「リンク」フィールドのリンク番号を使用した接続が確立された場合にのみ合法です。フィールドFMとFBは、現在のメッセージスペース割り当ての分数（128分の1）と（それぞれ）返される（それぞれ）ビットスペース割り当てとして定義されます。いずれかの画分が1以上の場合、対応する割り当ての_all_を返す必要があります。輸送中のメッセージを使用すると、送信者と受信者は、あらゆる時点での実際の割り当てに同意できないため、画分が使用されます。
Upon receiving a GVB command, the sending Host must return _at_ _least_* the requested portions of the message and bit space allocations. (A sending Host is prohibited from spontaneously returning portions of the message and bit space allocations.) The control command for performing this function is RET (return).
GVBコマンドを受信すると、送信ホストは_AT_ _ LEAST_*メッセージの要求された部分とビットスペース割り当てを返す必要があります。（送信ホストは、メッセージの一部を自発的に返却することを禁止されています。）この関数を実行するための制御コマンドはRET（RETURN）です。
[*In particular, fractional returns must be rounded up, not truncated.]
[*特に、分数のリターンは切り捨てられないように切り上げなければなりません。]
8 8 16 32
+------------------------------------+
| RET | link | msg space | bit space |
+------------------------------------+
This command is sent only from the sending Host to the receiving Host, and is legal only when a connection using the link number in the "link" field is established and a GVB command has been received from the receiving Host. The "msg space" field and the "bit space" field are defined as unsigned binary integers specifying the amounts by which the sender's message counter and bit counter (respectively) have been decremented due to the RET activity (i.e., the amounts of message and bit space allocation being returned). NCPs are obliged to answer a GVB with a RET "quickly"; however, there is _no_ prescribed time period in which the answering RET must be sent.
このコマンドは、送信ホストから受信ホストにのみ送信され、「リンク」フィールドのリンク番号を使用した接続が確立され、受信ホストからGVBコマンドが受信された場合にのみ合法です。「MSGスペース」フィールドと「ビットスペース」フィールドは、送信者のメッセージカウンターとビットカウンターが（それぞれ）アクティビティのために（つまり、メッセージと量の量と量が減少した量を指定する未署名のバイナリ整数として定義されます。ビットスペース割り当てが返されます）。NCPは、ret "迅速な"でGVBに回答する義務があります。ただし、回答RETを送信する必要がある_NO_処方期間があります。
Some Hosts will allocate only as much space as they can guarantee for each link. These Hosts will tend to use the GVB command only to reclaim space which is being filled very slowly or not at all. Other Hosts will allocate more space than they have, so that they may use their space more efficiently. Such a Host will then need to use the GVB command when the input over a particular link comes faster than it is being processed.
一部のホストは、各リンクに対して保証できる限り多くのスペースのみを割り当てます。これらのホストは、GVBコマンドを使用して、非常にゆっくりと充填されているか、まったく充填されていないスペースを取り戻す傾向があります。他のホストは、自分よりも多くのスペースを割り当てるため、スペースをより効率的に使用できます。そのようなホストは、特定のリンク上の入力が処理されているよりも速くなる場合、GVBコマンドを使用する必要があります。
Interrupts
==========
The second level protocol has included a mechanism by which the transmission over a connection may be "interrupted." The meaning of
第2レベルのプロトコルには、接続を介した伝送が「中断」される可能性があるメカニズムが含まれています。の意味
the "interrupt" is not defined at this level, but is made available for use by outer layers of protocol. The interrupt command sent from the receiving Host to the sending Host is INR (interrupt-by-receiver).
「割り込み」はこのレベルでは定義されていませんが、プロトコルの外層で使用できるようになります。受信ホストから送信ホストに送信された割り込みコマンドはINRです（割り込みごとのレシーバー）。
8 8
+------------+
| INR | link |
+------------+
The interrupt command sent from the sending Host to the receiving Host is INS (interrupt-by-sender).
送信ホストから受信ホストに送信された割り込みコマンドはINS（割り込みごと）です。
8 8
+------------+
| INS | link |
+------------+
The INR and INS commands are legal only when a connection using the link number in the "link" field is established.
INRおよびINSコマンドは、「リンク」フィールドのリンク番号を使用した接続が確立されている場合にのみ合法です。
Test Inquiry
============
It may sometimes be useful for one Host to determine if some other Host is capable of carrying on network conversations. The control command to be used for this purpose is ECO (echo).
1人のホストが他のホストがネットワーク会話を続けることができるかどうかを判断するのに役立つ場合があります。この目的に使用される制御コマンドはECO（ECHO）です。
8 8
+------------+
| ECO | data |
+------------+
The "data" field may contain any bit configuration chosen by the Host sending the ECO. Upon receiving an ECO command an NCP must respond by returning the data to the sender in an ERP (echo-reply) command.
「データ」フィールドには、エコを送信するホストが選択したビット構成を含めることができます。ECOコマンドを受信すると、NCPはERP（Echo-Reply）コマンドで送信者にデータを返すことにより応答する必要があります。
8 8
+------------+
| ERP | data |
+------------+
A Host should "quickly" respond (with an ERP command) to an incoming ECO command. However, there is no prescribed time period, after the receipt of an ECO, in which the ERP must be returned. A Host is prohibited from sending an ERP when no ECO has been received, or from sending an ECO to a Host while a previous ECO to that Host remains
ホストは、（ERPコマンドを使用して）eCOコマンドに「迅速に」応答する必要があります。ただし、ERPを返却する必要があるECOの受領後、規定の期間はありません。エコが受け取られていないときにホストはERPを送信することを禁止しているか、以前のエコがそのホストに残っている間、エコをホストに送信することは禁止されています
"unanswered." Any of the following constitute an "answer" to an ECO: information from the local IMP that the ECO was discarded by the network (e.g., IMP/Host message type 7 - Destination Dead), ERP, RST, or RRP (see below).
「未回答。」次のいずれかは、エコに対する「答え」を構成します。エコがネットワークによって破棄されたというローカルIMPからの情報（例：IMP/ホストメッセージタイプ7-デスティネーションデッド）、ERP、RST、またはRRP（以下を参照）。
Reinitialization
================
Occasionally, due to lost control messages, system "crashes", NCP errors, or other factors, communication between two NCPs will be disrupted. One possible effect of any such disruption might be that neither of the involved NCPs could be sure that its stored information regarding connections with the other Host matched the information stored by the NCP of the other Host. In this situation, an NCP may wish to reinitialize its tables and request that the other Host do likewise; for this purpose the protocol provides the pair of control commands RST (reset) and RRP (reset-reply).
時折、コントロールメッセージの紛失、システムの「クラッシュ」、NCPエラー、またはその他の要因により、2つのNCP間の通信が破壊されます。そのような混乱の可能性のある効果の1つは、関係するNCPのどちらも、他のホストとの接続に関する保存された情報が他のホストのNCPによって保存されている情報と一致することを確信できないことです。この状況では、NCPはそのテーブルを再現し、他のホストが同様に行うことを要求したい場合があります。この目的のために、プロトコルは、コントロールコマンドのペアRST（リセット）とRRP（RESET-REPLY）を提供します。
8
+-----+
| RST |
+-----+
8
+-----+
| RRP |
+-----+
The RST command is to be interpreted by the Host receiving it as a signal to purge its NCP tables of any entries which arose from communication with the Host which sent the RST. The Host sending the RST should likewise purge its NCP tables of any entries which arise from communication with the Host to which the RST was sent. The Host receiving the RST should acknowledge receipt by returning an RRP. _Once_the_first_Host_has_sent_an_RST_to_the_second_Host,_the_first_ _Host_is_not_obliged_to_communicate_with_the_second_Host_(except_for_ _responding_to_RST)_until_the_second_Host_returns_an_RRP._ In fact, to avoid synchronization errors, the first Host _should_not_ communicate with the second until the RST is answered. Of course, if the IMP subnetwork returns a "Destination Dead" (type 7) message in response to the control message containing the RST, an RRP should not be expected. If both NCPs decide to send RSTs at approximately the same time, then each Host will receive an RST and each must answer with an RRP, even though its own RST has not yet been answered.
最初のコマンドは、ホストを受け取るホストによって解釈されます。これは、RSTを送信したホストとのコミュニケーションから生じるエントリのNCPテーブルをパージするための信号として解釈されます。最初に送信するホストは、同様に、RSTが送信されたホストとの通信から生じるエントリのNCPテーブルをパージする必要があります。 RRPを返すことにより、最初のホストを受け取ったホストは領収書を確認する必要があります。 _Once_the_first_Host_has_sent_an_RST_to_the_second_Host,_the_first_ _Host_is_not_obliged_to_communicate_with_the_second_Host_(except_for_ _responding_to_RST)_until_the_second_Host_returns_an_RRP._ In fact, to avoid synchronization errors, the first Host _should_not_ communicate with the second until the RST is answered.もちろん、IMPサブネットワークがRSTを含むコントロールメッセージに応じて「Destination Dead」（タイプ7）メッセージを返した場合、RRPは予想されるべきではありません。両方のNCPがほぼ同時にRSTSを送信することを決定した場合、各ホストはRSTを受け取り、それぞれがRRPで回答する必要がありますが、独自のRSTはまだ回答されていません。
Some Hosts may choose to "broadcast" RSTs to the entire network when they "come up." One method of accomplishing this would be to send an
一部のホストは、「登場する」ときにネットワーク全体にRSTSを「ブロードキャスト」することを選択できます。これを達成する1つの方法は、
RST command to each of the 256 possible Host addresses; the IMP subnetwork would return a "Destination Dead" (type 7) message for each non-existent Host, as well as for each Host actually "dead." _However,_no_Host_is_ever_obliged_to_transmit_an_RST_command._
256の可能なホストアドレスのそれぞれに対する最初のコマンド。IMPサブネットワークは、存在しない各ホストと、実際に「死んでいる」各ホストの「Destination Dead」（タイプ7）メッセージを返します。_hhohver、_no_host_is_ever_obliged_to_transmit_an_rst_command._
Hosts are prohibited from sending an RRP when no RST has been received. Further, Hosts may send only one RST in a single control message and should wait a "reasonable time" before sending another RST to the same Host. Under these conditions, a single RRP constitutes an "answer" to _all_ RSTs sent to that Host, and any other RRPs arriving from that Host should be discarded.
ホストは、RSTが受信されていない場合にRRPを送信することを禁止されています。さらに、ホストは1つのコントロールメッセージで1つのRSTのみを送信することができ、同じホストに別のRSTを送信する前に「合理的な時間」を待つ必要があります。これらの条件下では、単一のRRPがそのホストに送信される_all_ RSTに対する「回答」を構成し、そのホストから到着する他のRRPを破棄する必要があります。
IV. DECLARATIVE SPECIFICATIONS
IV。宣言仕様
Message Format
==============
All Host-to-Host messages (i.e., messages of type zero) shall have a header 72 bits long consisting of the following fields (see Figure 1):
すべてのホストからホストへのメッセージ（つまり、タイプゼロのメッセージ）には、次のフィールドで構成されるヘッダー72ビットがあります（図1を参照）。
Bits 1-32 Leader - The contents of this field must be constructed according to the specifications contained in BBN Report Number 1822.
ビット1-32リーダー - このフィールドの内容は、BBNレポート番号1822に含まれる仕様に従って構築する必要があります。
Bits 33-40 Field M1 - Must be zero.
ビット33-40フィールドM1-ゼロでなければなりません。
Bits 41-48 Field S - Connection byte size. This size must be identical to the byte size in the STR used in establishing the connection. If this message is being transmitted over the control link the connection byte size must be 8.
ビット41-48フィールドS-接続バイトサイズ。このサイズは、接続の確立に使用されるSTRのバイトサイズと同じでなければなりません。このメッセージがコントロールリンクを介して送信されている場合、接続バイトサイズは8でなければなりません。
Bits 49-64 Field C - Byte Count. This field specifies the number of bytes in the text portion of the message. A zero value in the C field is explicitly permitted.
ビット49-64フィールドC-バイトカウント。このフィールドは、メッセージのテキスト部分のバイト数を指定します。Cフィールドのゼロ値は明示的に許可されています。
Bits 65-72 Field M2 - Must be zero.
ビット65-72フィールドM2-ゼロでなければなりません。
Following the header, the message shall consist of a text field of C bytes, where each byte is S bits in length. Following the text there will be field M3 followed by padding. The M3 field is zero or more bits long and must be all zero; this field may be used to fill out a message to a word boundary.
ヘッダーに続いて、メッセージはCバイトのテキストフィールドで構成され、各バイトの長さはsビットです。テキストに続いて、フィールドM3に続いてパディングが続きます。M3フィールドはゼロ以上の長さで、すべてゼロでなければなりません。このフィールドは、単語の境界へのメッセージを入力するために使用できます。
|<---------------------------32 bits--------------------------->|
|<----8 bits--->|<----8 bits--->|<-----------16 bits----------->|
+---------------------------------------------------------------+
| |
| LEADER |
| |
+---------------------------------------------------------------|
| | | |
| FIELD M1 | FIELD S | FIELD C |
| | | |
+---------------+---------------+-------------------------------+
| | ^ |
| FIELD M2 | | |
| | | |
+---------------+ | |
| | |
| | |
| | |
| | |
| TEXT |
| | |
| | |
| | |
| | |
| | +--------------------+
| | | |
| | | FIELD M3 |
| V | |
+-----------------------------------+------+--------------------+
| |
| 10-----------------0 |<-------PADDING
| |
+-----------------------------------+
Figure 1
========
The message header must, among other things, enable the NCP at the receiving Host to identify correctly the connection over which the message was sent. Given a set of messages from Host A to Host B, the only field in the header under the control of the NCP at Host B is the link number (assigned via the RTS control command). Therefore, each NCP must insure that, at a given point in time, for each connection for which it is the receiver, a unique link is assigned. Recall that the link is specified by the sender's address and the link number; thus a unique link number must be assigned to each connection to a given Host.
メッセージヘッダーは、とりわけ、受信ホストのNCPがメッセージが送信された接続を正しく識別できるようにする必要があります。ホストAからホストBへのメッセージのセットが与えられた場合、ホストBのNCPの制御下にあるヘッダーの唯一のフィールドはリンク番号（RTS制御コマンドを介して割り当てられています）です。したがって、各NCPは、特定の時点で、それが受信機である各接続に対して、一意のリンクが割り当てられることを保証する必要があります。リンクは、送信者のアドレスとリンク番号によって指定されていることを思い出してください。したがって、特定のホストへの各接続に一意のリンク番号を割り当てる必要があります。
Link Assignment
===============
Links are assigned as follows:
リンクは次のように割り当てられます。
Link number Assignment
=========== ==========
0 Control link
0制御リンク
2-71 Available for connections
2-71接続に利用可能
1, 72-190 Reserved - not for current use
1、72-190予約済み - 現在の使用ではありません
191 To be used only for measurement work under the direction of the Network Measurement Center at UCLA
191 UCLAのネットワーク測定センターの方向の下での測定作業にのみ使用される
192-255 Available for private experimental use.
192-255プライベートな実験的使用に利用できます。
Control Messages
================
Messages sent over the control link have the same format as other Host-to-Host messages. The connection byte size (Field S in the message header) must be 8. Control messages may not contain more than 120 bytes of text; thus the value of the byte count (Field C in the message header) must be less than or equal to 120.
コントロールリンクで送信されたメッセージは、他のホストからホストへのメッセージと同じ形式を持っています。接続バイトサイズ（メッセージヘッダー内のフィールドs）は8でなければなりません。コントロールメッセージには、120バイト以上のテキストを含むことはできません。したがって、バイトカウントの値（メッセージヘッダーのフィールドC）は120以下でなければなりません。
Control messages must contain an integral number of control commands. A single control command may not be split into parts which are transmitted in different control messages.
制御メッセージには、積分数の制御コマンドが含まれている必要があります。単一のコントロールコマンドを、異なるコントロールメッセージに送信する部品に分割されない場合があります。
Control Commands
================
Each control command begins with an 8-bit _opcode._ These opcodes have values of 0, 1, ... to permit table lookup upon receipt. Private experimental protocols should be tested using opcodes of 255, 254, ... Most of the control commands are more fully explained in Section III.
各コントロールコマンドは、8ビット_opcode._これらのオプコードの値を0、1、...領収書時にテーブルの検索を許可する値から始まります。255、254のオペコードを使用して、プライベート実験プロトコルをテストする必要があります...ほとんどの制御コマンドは、セクションIIIでより完全に説明されています。
NOP - No operation
==================
8
+-----+
| NOP |
+-----+
The NOP command may be sent at any time and should be discarded by the receiver. It may be useful for formatting control messages.
NOPコマンドはいつでも送信される場合があり、受信機によって廃棄される必要があります。制御メッセージのフォーマットに役立つ場合があります。
RST - Reset
===========
8
+-----+
| RST |
+-----+
The RST command is used by one Host to inform another that all information regarding previously existing connections, including partially terminated connections, between the two Hosts should be purged from the NCP tables of the Host receiving the RST. Except for responding to RSTs, the Host which sent the RST is not obliged to communicate further with the other Host until an RRP is received in response.
RSTコマンドは、あるホストによって使用され、別のホストに、部分的に終了した接続を含む以前に既存の接続に関するすべての情報が、2つのホスト間のすべての情報を、RSTを受信するホストのNCPテーブルからパージする必要があることを通知します。RSTSに応答することを除いて、RSTを送信したホストは、RRPが応答して受信するまで他のホストとさらに通信する義務はありません。
RRP - Reset reply
=================
8
+-----+
| RRP |
+-----+
The RRP command must be sent in reply to an RST command.
RRPコマンドは、RSTコマンドに返信して送信する必要があります。
RTS - Request connection, receiver to sender
============================================
8 32 32 8
+----------------------------------------------+
| RTS | receive socket | send socket | link |
+----------------------------------------------+
The RTS command is used to establish a connection and is sent from the Host containing the receive socket to the Host containing the send socket. The link number for message transmission over the
RTSコマンドは接続を確立するために使用され、受信ソケットを含むホストから送信ソケットを含むホストに送信されます。メッセージ送信のリンク番号
connection is assigned with this command; the "link" field must be between 2 and 71, inclusive.
接続はこのコマンドに割り当てられます。「リンク」フィールドは、2〜71の間でなければなりません。
STR - Request connection, sender to receiver
============================================
8 32 32 8
+----------------------------------------------+
| STR | send socket | receive socket | size |
+----------------------------------------------+
The STR command is used to establish a connection and is sent from the Host containing the send socket to the Host containing the receive socket. The connection byte size is assigned with this command; the size must be between 1 and 255, inclusive.
STRコマンドは接続を確立するために使用され、受信ソケットを含むホストに送信ソケットを含むホストから送信されます。接続バイトサイズは、このコマンドに割り当てられます。サイズは1〜255の間で、包括的でなければなりません。
CLS - Close
===========
8 32 32
+-----+-------------+-------------+
| CLS | my socket | your socket |
+-----+-------------+-------------+
The CLS command is used to terminate a connection. A connection need not be completely established before a CLS is sent.
CLSコマンドは、接続を終了するために使用されます。CLSが送信される前に、接続を完全に確立する必要はありません。
ALL - Allocate
==============
8 8 16 32
+------------------------------------+
| ALL | link | msg space | bit space |
+------------------------------------+
The ALL command is sent from a receiving Host to a sending Host to increase the sending Host's space counters. This command may be sent only while the connection is established. The receiving Host is prohibited from incrementing the Host's message counter above (2^16 - 1) or bit counter above (2^32 - 1).
すべてのコマンドは、受信ホストから送信ホストに送信され、送信ホストのスペースカウンターが増加します。このコマンドは、接続が確立されている間にのみ送信できます。受信ホストは、上記（2^16-1）またはビットカウンター（2^32-1）の上のホストのメッセージカウンターを増やすことを禁止されています。
GVB - Give back
===============
8 8 8 8
+----------------------+
| GVB | link | fm | fb |
+----------------------+
^ ^
| +--- bit fraction
+-------- message fraction
The GVB command is sent from a receiving Host to a sending Host to request that the sending Host return all or part of its message space and/or bit space allocations. The "fractions" specify what portion (in 128ths) of each allocation must be returned. This command may be sent only while the connection is established.
GVBコマンドは、受信ホストから送信ホストに送信され、送信ホストがメッセージスペースおよび/またはビットスペースの割り当てのすべてまたは一部を返すように要求します。「分数」は、各割り当てのどの部分（128分の1）を返しなければならないかを指定します。このコマンドは、接続が確立されている間にのみ送信できます。
RET - Return
============
8 8 16 32
+------------------------------------+
| RET | link | msg space | bit space |
+------------------------------------+
The RET command is sent from the sending Host to the receiving Host to return all or a part of its message space and/or bit space allocations in response to a GVB command. This command may be sent only while the connection is established.
RETコマンドは、送信ホストから受信ホストに送信され、GVBコマンドに応じてメッセージスペースおよび/またはビットスペース割り当てのすべてまたは一部を返します。このコマンドは、接続が確立されている間にのみ送信できます。
INR - Interrupt by receiver
===========================
8 8
+------------+
| INR | link |
+------------+
The INR command is sent from the receiving Host to the sending Host when the receiving process wants to interrupt the sending process. This command may be sent only while the connection is established.
INRコマンドは、受信プロセスが送信プロセスを中断したい場合に、受信ホストから送信ホストに送信されます。このコマンドは、接続が確立されている間にのみ送信できます。
INS - Interrupt by sender
=========================
8 8
+------------+
| INS | link |
+------------+
The INS command is sent from the sending Host to the receiving Host when the sending process wants to interrupt the receiving process. This command may be sent only while the connection is established.
INSコマンドは、送信プロセスが受信プロセスを中断したい場合に、送信ホストから受信ホストに送信されます。このコマンドは、接続が確立されている間にのみ送信できます。
ECO - Echo request
==================
8 8
+------------+
| ECO | data |
+------------+
The ECO command is used only for test purposes. The data field may be any bit configuration convenient to the Host sending the ECO command.
ECOコマンドは、テスト目的でのみ使用されます。データフィールドは、ECOコマンドを送信するホストに便利なビット構成です。
ERP - Echo reply
================
8 8
+------------+
| ERP | data |
+------------+
The ERP command must be sent in reply to an ECO command. The data field must be identical to the data field in the incoming ECO command.
ERPコマンドは、ECOコマンドに返信して送信する必要があります。データフィールドは、着信ECOコマンドのデータフィールドと同一でなければなりません。
ERR - Error detected
====================
8 8 80
+-----+------+---------------------------- ~ -------------+
| ERR | code | data |
+-----+------+---------------------------- ~ -------------+
The ERR command may be sent whenever a second level protocol error is detected in the input from another Host. In the case that the error condition has a predefined error code, the "code" field specifies the specific error, and the data field gives parameters. For other
ERRコマンドは、別のホストからの入力で第2レベルのプロトコルエラーが検出されるたびに送信される場合があります。エラー条件に事前定義されたエラーコードがある場合、「コード」フィールドは特定のエラーを指定し、データフィールドはパラメーターを提供します。他のために
errors the code field is zero and the data field is idiosyncratic to the sender. Implementers of Network Control Programs are expected to publish timely information on their ERR commands.
エラーコードフィールドはゼロで、データフィールドは送信者にとって特異です。ネットワーク制御プログラムの実装者は、ERRコマンドに関するタイムリーな情報を公開することが期待されています。
The usefulness of the ERR command is compromised if it is merely discarded by the receiver. Thus, sites are urged to record incoming ERRs if possible, and to investigate their cause in conjunction with the sending site. The following codes are defined. Additional codes may be defined later.
ERRコマンドの有用性は、単に受信機によって破棄されている場合に侵害されます。したがって、サイトは、可能であれば、着信ERRを記録し、送信サイトと併せてその原因を調査するように促されます。次のコードが定義されています。追加のコードは後で定義できます。
a. Undefined (Error code = 0) The "data" field is idiosyncratic to the sender.
a. 未定義（エラーコード= 0）「データ」フィールドは、送信者にとって特異です。
b. Illegal opcode (Error code = 1) An illegal opcode was detected in a control message. The "data" field contains the ten bytes of the control message beginning with the byte containing the illegal opcode. If the remainder of the control message contains less than ten bytes, fill will be necessary; the value of the fill is zeros.
b. 違法なオペコード（エラーコード= 1）コントロールメッセージで違法なオペコードが検出されました。「データ」フィールドには、違法なオペコードを含むバイトから始まるコントロールメッセージの10バイトが含まれています。コントロールメッセージの残りの部分が10バイト未満に含まれている場合、塗りつぶしが必要になります。塗りつぶしの値はゼロです。
c. Short parameter space (Error code = 2) The end of a control message was encountered before all the required parameters of the control command being decoded were found. The "data" field contains the command in error; the value of any fill necessary is zeros.
c. 短いパラメーター空間（エラーコード= 2）コントロールメッセージの終わりが、デコードされるコントロールコマンドのすべての必要なパラメーターが見つかる前に遭遇しました。「データ」フィールドには、コマンドが含まれています。必要な充填の値はゼロです。
d. Bad parameters (Error code = 3) Erroneous parameters were found in a control command. For example, two receive or two send sockets in an STR, RTS, or CLS; a link number outside the range 2 to 71 (inclusive); an ALL containing a space allocation too large. The "data" field contains the command in error; the value of any fill necessary is zeros.
d. 悪いパラメーター（エラーコード= 3）コントロールコマンドで誤ったパラメーターが見つかりました。たとえば、2つはSTR、RTS、またはCLSでソケットを送信します。範囲2から71の外側のリンク番号（包括的）;スペース割り当てが大きすぎるすべてのものが含まれています。「データ」フィールドには、コマンドが含まれています。必要な充填の値はゼロです。
e. Request on a non-existent socket (Error code = 4) A request other than STR or RTS was made for a socket (or link) for which no RFC has been transmitted in either direction. This code is meant to indicate to the NCP receiving it that functions are being performed out of order. The "data" field contains the command in error; the value of any fill necessary is zeros.
e. 存在しないソケット（エラーコード= 4）のリクエストSTRまたはRTS以外のリクエストは、どちらの方向にもRFCが送信されていないソケット（またはリンク）に対して行われました。このコードは、機能が順調に実行されていることを受信するNCPに示すことを目的としています。「データ」フィールドには、コマンドが含まれています。必要な充填の値はゼロです。
f. Socket (link) not connected (Error code = 5) There are two cases:
f. ソケット（リンク）接続されていない（エラーコード= 5）2つのケースがあります。
1. A control command other than STR or RTS refers to a socket (or link) which is not part of an established connection. This code would be used when one RFC had been transmitted, but the matching RFC had not. It is meant to indicate the
1. STRまたはRTS以外の制御コマンドは、確立された接続の一部ではないソケット（またはリンク）を指します。このコードは、1つのRFCが送信されたときに使用されますが、一致するRFCは使用していませんでした。それを示すことを意図しています
failure of the NCP receiving it to wait for a response to an RFC. The "data" field contains the command in error; the value of any fill necessary is zeros.
NCPがRFCへの応答を待つためにそれを受け取ったことが失敗します。「データ」フィールドには、コマンドが含まれています。必要な充填の値はゼロです。
2. A message was received over a link which is not currently being used for any connection. The contents of the "data" field are the message header followed by the first eight bits of text (if any) or zeros.
2. 現在、接続には使用されていないリンクを介してメッセージが受信されました。「データ」フィールドの内容は、メッセージヘッダーに続いて、最初の8ビットのテキスト（もしあれば）またはゼロです。
Opcode Assignment
=================
Opcodes are defined to be eight-bit unsigned binary numbers. The values assigned to opcodes are:
オペコードは、8ビットの符号なしバイナリ番号であると定義されています。opcodesに割り当てられた値は次のとおりです。
NOP = 0 RTS = 1 STR = 2 CLS = 3 ALL = 4 GVB = 5 RET = 6 INR = 7 INS = 8 ECO = 9 ERP = 10 ERR = 11 RST = 12 RRP = 13
nop = 0 rts = 1 str = 2 cls = 3 all = 4 gvb = 5 ret = 6 inr = 7 ins = 8 eco = 9 erp = 10 err = 11 rst = 12 rrp = 13
Control Command Summary
=======================
8
+-----+
| NOP |
+-----+
8 32 32 8
+----------------------------------------------+
| RTS | receive socket | send socket | link |
+----------------------------------------------+
8 32 32 8
+----------------------------------------------+
| STR | send socket | receive socket | size |
+----------------------------------------------+
8 32 32
+-----+-------------+-------------+
| CLS | my socket | your socket |
+-----+-------------+-------------+
8 8 16 32
+------------------------------------+
| ALL | link | msg space | bit space |
+------------------------------------+
8 8 8 8
+----------------------+
| GVB | link | fm | fb |
+----------------------+
8 8 16 32
+------------------------------------+
| RET | link | msg space | bit space |
+------------------------------------+
8 8
+------------+
| INR | link |
+------------+
8 8
+------------+
| INS | link |
+------------+
8 8
+------------+
| ECO | data |
+------------+
8 8
+------------+
| ERP | data |
+------------+
8 8 80
+-----+------+---------------------------- ~ -------------+
| ERR | code | data |
+-----+------+---------------------------- ~ -------------+
8
+-----+
| RST |
+-----+
8
+-----+
| RRP |
+-----+
[ This is the end of the January 1972 document. ]
[これは1972年1月の文書の終わりです。]
This document does not discuss any security considerations.
このドキュメントでは、セキュリティ上の考慮事項については説明していません。
Authors' Addresses
著者のアドレス
Alexander McKenzie PMB #4334, PO Box 2428 Pensacola, FL 32513 USA EMail: amckenzie3@yahoo.com
Alexander McKenzie PMB＃4334、PO Box 2428 Pensacola、FL 32513 USAメール：amckenzie3@yahoo.com
Steve Crocker 5110 Edgemoor Lane Bethesda, MD 20814 USA EMail: steve@stevecrocker.com
Steve Crocker 5110 Edgemoor Lane Bethesda、MD 20814 USAメール：steve@stevecrocker.com