RFC 6529 - Host/Host Protocol for the ARPA Network 日本語訳

URL : https://tools.ietf.org/html/rfc6529
タイトル : RFC 6529 - アーパネットのためのホスト/ホストプロトコル
翻訳編集 : 自動生成

Independent Submission                                       A. McKenzie
Request for Comments: 6529                                    S. Crocker
Category: Historic                                            April 2012
ISSN: 2070-1721

                Host/Host Protocol for the ARPA Network

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年の間、ARPAネットワークワーキンググループによって開発されたホスト/ホストプロトコルを再生し、1971年には独立したホスト上に存在するプロセス間の通信を管理するために使用されるプロトコルについて説明します。これは、単一のハードウェア・インタフェースを介して（制御、コネクション確立/ disestablishment、および他のシグナル伝達を流れ、アドレッシングを含む）通信の多重化複数のストリームの問題に対処します。 RFCシリーズを通して利用可能な歴史的な記録を完了するために、この後半の日にRFCとして提供される1月1983年におけるTCP / IPへの切り替えまでの1972年1月からアーパネットの公式プロトコルでした。

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 Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 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.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6529で取得することができます。

著作権表示

著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

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

1. Introduction

1. はじめに

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.

アーパネットのためのホスト/ホストプロトコルはスティーブクロッカー、UCLAの大学院生が議長を務め、ネットワークワーキンググループによって1969年、1970年、および1971年の間に作成されました。 72未満の番号のRFCの多く、プラスのRFC 102、107、111、124、132、154、及び179は、このプロトコルの開発に対処。プロトコルを画定する第1の公文書はクロッカー、ポステル、ニューカーク、及びKraleyによってRFC 54に基づいた「ホスト - ホストプロトコル文献1」（RFC 65で引用を参照）として1970年8月3日にクロッカーによって発行されました。 RFC 102で説明したように文献1の改正は、マッケンジーは、文献1に取って代わら1972年1月の文書の著者としてリストされているが、マッケンジーは誰一人だったと言う方が正確である、半ば1971年2月に始まりましたコンパイルして、文書を編集しました。ほとんどまたはドキュメント内のアイデアのすべてが他の人と起源。

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.

当時「ホストホストプロトコル文献1には、」それは「コメント要求」としてではなく、実装のための標準として見られることはなかったので、それはRFC番号が与えられていなかった発行されました。これは、スタンフォード研究所のネットワーク情報センター（NIC）（SRI）によるドキュメントの別個のセットとして維持このような標準のセットの1つでした。 1972年1月版（8246 NIC）も、そのアプローチを踏襲し、ここに再現しました。以降のすべての標準が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年、アーパネットの文書、RFCおよびその他のほとんどは、ハードコピーで作成・配布されました。ホスト/ホストプロトコル文書は、交換可能なプリント要素を持っていて、通常のフォントに加えて、イタリックと太字フォントの両方を使用するタイプライター（おそらくIBM Selectric）、上で入力しました。図は、グラフィックアーティストによって描かれ、入力された文書に貼り付けました。 RFCには、単一の書体を使用するように制限されているので、我々はすべて大文字のいずれかを使用することによって、または二重下線で太字を示すために、スペースの代わりに、言葉の周りにアンダースコアを使用することによって、イタリックを示すために試してみました。得られた文書が読み少しより困難であるが、元の強調を維持します。もちろん、改ページが変更されている、と私たちは正しくページ番号のすべてを変更している願っています。そこ3つの脚注は、元の文書にあったと我々はインデントと角括弧ではオフに設定されたテキストの中にこれらを移動しました。原稿の.PDF画像がhttp://www.cbi.umn.edu/hostedpublications/pdf/McKenzieNCP1972.pdfで見つけることができます。

2. A Few Comments on Nomenclature and Key Concepts

2.命名法上のいくつかのコメントとキーコンセプト

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に取って代わられました。現在の文章に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.

プロトコルの設計に制約をタイミングに関する不確実性は、この文書で明らかであり、今日の設計プロセスにおける曖昧さ、制限、およびエラーの原因のまま。

3. Host/Host Protocol Document

3.ホスト/ホストプロトコル文書

                              Host/Host Protocol
                                   for the
                                 ARPA Network

Prepared for the Network Working Group by Alex McKenzie BBN January 1972

アレックスマッケンジー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ネットワークプロトコルのを指定します。すべてのプロトコル仕様は、文書_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コマンド - のRFC（14ページ）をキューイングキューイングとしない場合の影響についての議論 - - 未回答のCLSコマンド（16ページ）の問題の議論ERRコマンドを受信した強い推薦があることログインして、いくつかの追加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

スティーブクロッカー高等研究計画庁1400ウィルソン大通りアーリントン、バージニア州22209（202）694から5921または5922

Alex McKenzie Bolt Beranek and Newman Inc. 50 Moulton Street Cambridge, Massachusetts 02133 (617) 491-1350 ext. 441

アレックスマッケンジーボルトBeranekとニューマン株式会社50モールトンストリートケンブリッジ、マサチューセッツ州02133（617）491から1350内線。 441

Jon Postel University of California at Los Angeles Computer Science Department 3732 Boelter Hall Los Angeles, California 90024 (213) 325-2363

ロサンゼルスコンピュータサイエンス学部のカリフォルニアのジョン・ポステル大学3732 Boelterホールロサンゼルス、カリフォルニア州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へのメッセージを保存して転送するようにプログラムされています。典型的な動作中に、ホストは、ローカル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の間の物理的および論理的なメッセージ転送のための仕様は、これらの仕様は、一般_first_level_protocol_またはホスト/ IMPプロトコルと呼ばれるボルトBeranekとニューマン（BBN）報告書番号1822に含まれています。このプロトコルは、しかし、自身が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、_またはHost /ホストプロトコルとして知られています。プロトコルのさらなる層の例は、現在開発または予想される（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）ネットワーク仮想端末（NVT）に任意のキーボード・プリンタ端末の「マッピング」を提供_Telecommunication_Network_（TELNET）プロトコルは、一つのホストサイトのユーザ端末と一部の端末サービングプロセス間の通信を容易にします「期待」は、他の部位は、使用中の実際の（リモート）端子から論理的に異なる（ローカル）端子に接続されます。 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）A _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.

この文書の残りの部分は説明及びネットワークワーキンググループによって処方としてホスト/ホスト、又は第二レベル、プロトコルを指定します。

II. COMMUNICATION CONCEPTS

II。通信CONCEPTS

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つ以上のプロセスを実行している各ユーザーに、複数のユーザーをサポートすることができます。これらのプロセスの多くは、同時にネットワークを使用することができ、したがって、ホスト/ホスト・プロトコルの基本的な要件は、ネットワークを介してプロセス間通信を提供することです。第一レベルのプロトコルは、ホストのみの認識がかかるため、および宿主内で実行中のいくつかのプロセスは、通常、独立しているので、第二レベルのプロトコルは、より豊富なアドレッシング構造を提供することが必要です。

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つのプロセスから別のものに、そのようなデータベースとして、情報の大体の送信です。別の例は、多くの取引所との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.

ホスト内のプロセスは、第二レベル・プロトコルを実装し、そのホストに常駐し、_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によって解釈されなければならないように指定されています。例えば、制御コマンドの一種類は、他の種類の接続が終了した通知を搬送しながら、接続を開始するために使用されます。

[*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（というより、各送信処理）をネットワークメッセージにプロセス間通信を分割するための責任であることが決定されています。したがって、それは有意に受信処理することにより、メッセージの境界から推測されなくてもよい第二レベルのプロトコルの主です。 _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._上の接続を介して送信される各メッセージに同意しなければならない関連するプロセスは、このサイズのバイトの整数を含んでいなければなりません。したがって、接続に関与するプロセスの対は、例えば、その宿主ワード長の最小公倍数を互いに便利バイトのサイズを選択することができます。バイトサイズを選択する能力は、接続に関連するプロセスに利用できるように_必ず_ことに注意することが重要です。 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ビットは、宛先ホストアドレスとリンク番号を含むアドレス情報を含んでいることが必要です。第二レベルのプロトコルは、72ビットの合計に対する各メッセージの先頭に必要な情報を拡張します。これらの72ビットは、ほとんどのホストのいずれかがデータの8ビット単位で都合よく働くか、18または36ビットのワード長を有することができるので、72ビットの長さが選択される_message_header._呼ばれます。 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.

第二レベル・プロトコルの別の主要な関心事は、他のホストにプロセスを参照するための方法です。各ホストには、プロセスに名前を付けるためのいくつかの内部の方式がありますが、これらの様々なスキームは、典型的には、異なっていても、互換性がない可能性があります。それは共通の内部プロセス命名規則を課すことは実用的ではないので、標準的な中間名前空間は、各ホストに割り当てられた名前空間の別の部分で使用されます。各ホストは、この名前空間のその部分に内部プロセス識別子をマッピングする能力を持っている必要があります。

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 =送信）。このプロパティは、接続の両端のソケットは反対の性別のものでなければならない、ソケットの_gender._と呼ばれています。性別を除いて、第二レベルのプロトコルは、ホスト内のソケット番号の割り当てには制約を課すません。

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（送信者 - 受信器）及びRTS（TO-センダreceiver-）です。

           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命令が将来の送信者に将来の受信機に将来の送信者から送られ、将来の受信機からのRTSれます。将来の送信者へのローカル送信ソケットフィールド名ソケット。将来の受信機へのローカルソケットフィールド名のソケットを受けます。接続を介してすべてのメッセージに使用するバイトサイズを指定し、（ゼロが禁止されている1から255の範囲）STRコマンドで、「サイズ」フィールドは符号なし2進数を含んでいます。 RTSコマンドでは、「リンク」フィールドには、リンク番号を指定します。接続上のすべてのメッセージは、この番号で指定されたリンクを介して送信する必要があります。この2つのコマンドは、リクエスト-のための接続（のRFC）と呼ばれています。 STRとRTSの試合受信ソケットフィールドが一致し、送信ソケットフィールドが一致した場合。 RFCのマッチングペアが交換されたときに接続が確立されます。 _Hosts_are_prohibited_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._ホストが送信ソケットの一方にその受信ソケットのいずれかを接続することができると呼ばれる受信ソケットを含む宿主呼ばれホストとその接続の受信ホストを送信します。

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.

それは卓越したマッチングRFCを有していない場合は、直ちに_There_is_no_prescribed_lifetime_for_an_RFC._ホストが（以下接続終了を参照）要求を拒否し、代わりに、着信RFCをキューと任意の長い時間のために応答を保留することが許可されるか、または。 NCPは、ローカルプロセスがそのソケット番号を制御し、要求を受け入れるか拒否するNCPを指示するまで、いくつかの現在使用されていないソケットを指すRFCをキューすることは、例えば、合理的であってもよいです。もちろん、RFCを送ったホストは、任意の長さの時間を待つことを望まないかもしれ、それは要求を中止することがあります。一方、いくつかのNCP実装はRFCをキューイングするための任意の空間を含まなくてもよいので、RFCシーケンスがローカルに開始された場合を除きRFCを拒否することが期待できます。

_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).

キュー、またはキューではない、入ってくるのRFCの決定は、NCPの実装は無視してはならない重要な意味を持ちます。キューに登録された各RFCは、当然のことながら、キューイングをやってホストに少量のメモリを必要とします。ローカルプロセスは、ローカルソケットを捕捉し、RFCを受け入れ（または拒否）が、ローカルプロセスが今までソケットを捕捉なくなるまで各着信RFCがキューイングされている場合は、RFCは「永遠に。」キューに登録する必要があります理論的にはこれは、このようにRFCキューの無限のストレージを必要とする（ローカルプロセスがあれば、受け入れ先の、決定させる、単一のローカルソケットのいくつかのRFCをキューイングしない理由はありません）無限に何回も発生する可能性があります。いかなるキューイングが行われていない一方、上述の協働プロセスは、それらが他の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番目のオプションは、プロセスは、いくつかのリモートソケット（プロセスは、特定のリモートソケットを指定して、および/またはそれと通信することを希望するホストかもしれない）から、指定されたローカルソケットへのRFCのために、「聞く」こと_its_own_ NCPを伝えるためにして受け入れることが可能になりますRFC（すなわち、一致するRFCを返す）であれば、それが到着しました。これはまた、（「聞く」要求のキューイング）関与していることに注意してください、それがローカルホストによって合理的な管理を受けやすい内部キューイングです。この実装は使用可能であった場合は、他のプロセスが1が受け入れられたまでのRFCのシリーズが「リスニング」ソケットに送信される原因となった一方で、2つのつの協働のプロセスの一つは、「聞く」ことができます。それは何の害もしないだろうがこのように、入ってくるの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_ _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._

「私のソケット」フィールドには、CLSコマンドの送信者にローカルソケットが含まれています。「あなたのソケット」フィールドには、CLSコマンドの受信にローカルソケットが含まれています。 _Each_side_must_send_and_receive_a_ _CLS_command_before_connection_termination_is_completed_and_the_ _sockets_are_free_to_participate_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.

接続の終了を開始する前に、それは（_both_ RFCが交換される、すなわち、のために）確立される接続のために必要ではありません。ホストが接続要求を拒否したい場合たとえば、それは、CLSの代わりに一致するRFCを送り返します。拒否ホストは、CLSを返すことによって拒絶を認めることを開始するホストを待ちます。ホストが接続のためにその未処理の要求を中止することを希望する場合は同様に、それはCLSコマンドを送信します。外国人のホストは、自身のCLSでCLSを確認する義務があります。接続が確立されなかったにもかかわらず、ソケットが他の使用のために自由である前に、CLSコマンドを交換しなければならないことに注意してください。

After a connection is established, CLS commands sent by the receiver 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コマンドは、わずかに異なる効果を持っています。送信者によって送信されたCLSコマンドは、これ以上のメッセージが接続を介して送信されませんことを示しています。送信を終了するため、送信者への要求として受信機作用によって送ら_This_command_must_not_be_sent_if_there_is_a_message_ _in_transit_over_the_connection._ A 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がBをホストするためにCLSを送信したとします。しかし、AがBにそのCLSを送り、ちょうどその時、Bは接続を拒否することにCLSを送信します。「信じている」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は、AがCLSを送信するだけこの場合、実施例1と同様CLS続いRFCが、但し、Bがに一致するRFCを送信ホストBに送信すると仮定する。 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は、外国人のホストによって「すぐに」が返されていない場合はどうするかの問題に直面している（すなわち、外国人のホストがこの点で、プロトコルに違反していると思われている場合）。一つの素朴な答えが一致する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の可能性は、したがって、すべてのテーブルが両端に再初期化されることを可能にする、問題のあるホスト（ホストB）に（20ページを参照）RSTを送信するためにCLSコマンド（ホストA）と一致するのを待っているホストのためのものです。これは、これらの接続もRSTによって破壊されるため、ネットワーク接続を介してホストB上の有用な作業を実行するために起こったホスト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が受信されていない場合でも、接続を「忘れる」その後、いくつかの非公式のタイムアウト期間を採用しています。このような構成を有する危険性がソケットの同一の対の間の第二の接続が確立後、およびCLSは最終的に最初の接続のために到着した場合、第二の接続がクローズされる可能性があるということです。 1ホストの2つの方法で、プロトコルに違反している場合、このような状況では唯一の、しかし、発生することができます。まず、それは既に使用されていると考えているソケットを含むコネクションの確立を可能にすることにより、着信CLS、第二に迅速に対応することができないこともできます。ネットワークはいくつかの標準的なタイムアウト時間を採用することが示唆されているが、NWGが便利で、すべてのホストに受け入れられるのに十分な長さに十分に短いの両方の期間に到着することができませんでした。現在使用されているタイムアウト期間は間に約1分と約5分の範囲でいるように見えます。 _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._

   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 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_及び各カウンタは、接続が確立されたときにゼロに初期化されるとAS受信ホストから送信された割り当て（ALL）制御コマンドだけ増加さ_bit_counter._に関連する2つのカウンタを維持します以下で説明します。メッセージを送信する場合、送信ホストのNCPは、メッセージカウンタとビットカウンタから_text_length_（以下に定義）から1を減算します。送信者は、いずれかのカウンタがゼロ以下に減らされることになる場合、送信が禁止されます。送信ホストは、受信ホスト（下記参照）から所与バック（GVB）コマンドを受信すると、リターン（RET）コマンドを使用してメッセージまたはビット領域割当ての全て又は一部を戻すことができます。

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進整数であると定義されます。、又は（2 ^ 32 - 1）上記送信側のビットカウンタ - 受信機は、（1 2 ^ 16）上記送信側のカウンタをインクリメントが禁止されます。一般的には、このルールは、送信者のカウンターと同じ規則に従ってインクリメントとデクリメントされ、カウンタを維持するために、受信機が必要になります。

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（与えるバック）です。

           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が現在のメッセージ空間の割り当て及びビット空間割り当ての（128thsで）画分として定義される（それぞれ）返されます。画分のいずれかが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（リターン）です。

[*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空間」フィールドと「ビット空間」フィールドは、送信者のメッセージカウンタとビットカウンタ（それぞれが）によるRET活動に減算されたことにより、金額を指定する符号なし2進整数として定義されています（メッセージのすなわち、量とビット空間の割り当て）が返されます。 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 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).

あるホストが他のホストがネットワークの会話を運ぶことができるかどうかを決定することが時々有用であり得ます。この目的のために使用される制御コマンドは、ECO（エコー）です。

           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（エコー応答）コマンドで送信者にデータを返すことによって応答しなければならないECOコマンドを受信します。

           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

ホストは、「迅速」、着信ECOコマンドに（ERPコマンドで）応答する必要があります。しかし、所定時間は、ERPは、返却されなければならないECOの受領後、ありません。ホストは何のECOを受信していないERPを送るから、または前のECOながらホストにECOを送信するホスト遺跡に禁止されています

"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).

「未回答。」以下のいずれかのECOへの「答え」を構成する：ECOは、ネットワーク（例えば、IMP /ホストメッセージタイプ7 - デスティネーション・デッド）によって破棄されたことを地元のIMPからの情報、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間の通信が中断されます。このような混乱の一つの可能な効果は、関与のNCPのいずれもが、他のホストとの接続に関するその格納されている情報は、他のホストのNCPによって格納された情報と一致したことを確認することができることであるかもしれません。このような状況では、NCPは、そのテーブルを再初期化したいと他のホストも同様に行うことを要求することができます。この目的のためのプロトコルは、制御一対のRST（リセット）とRRP（リセット応答）にコマンドを提供します。

           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コマンドは、RSTを送信したホストとの通信から生じたすべてのエントリのそのNCPテーブルをパージするための信号として受信ホストによって解釈されるべきです。 RSTを送信するホストは同様に、RSTが送られた先のホストとの通信に起因する任意のエントリのそのNCPテーブルをパージする必要があります。 RSTを受けたホストは、RRPを返すことによって受信を確認する必要があります。 RSTが応答されるまで_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._は、同期エラーを回避するために、第一のホスト_should_not_は、第二連通します。 IMPサブネットワークは、RSTを含む制御メッセージに応答して「宛先デッド」（タイプ7）メッセージを返す場合はもちろん、RRPを期待すべきではありません。両方のNCPがほぼ同じ時刻にのRSTを送信することを決定した場合、各ホストはRSTを受け取り、それぞれが独自のRSTは、まだ回答されていないにもかかわらず、RRPで答えなければなりません。

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

彼らは「出てくる。」と、一部のホストがネットワーク全体に「放送」のRSTに選ぶことができますこれを達成する一つの方法は、送信することです

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個の可能なホストアドレスのそれぞれにRSTコマンド。 IMPサブネットワークは、だけでなく、実際には各ホストのために、それぞれ存在しないホストの「デスティネーション・デッド」（タイプ7）メッセージを返す「死にました。」 _However、_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を送信することは禁止されています。さらに、ホストは、単一の制御メッセージに一つだけRSTを送信することができ、同じホストに別のRSTを送信する前に、「合理的な時間」を待たなければなりません。これらの条件下で、単一RRPは、そのホストに送信_all_のRSTへの「答え」を構成し、そのホストから到着する他のRRPsは破棄されなければなりません。

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.

ヘッダに続いて、メッセージは、各バイトの長さがSビットであるCバイトのテキスト・フィールドで構成しなければなりません。テキスト以下のパディングが続くフィールド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を有効にする必要があります。 BをホストするホストAからのメッセージのセットが与えられると、ホスト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

UCLAでのネットワーク測定センターの指示の下でのみ測定作業に使用する191

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）は、テキストの120の以上のバイトを含んでいてもよい8制御メッセージでなければなりません。このようにバイト数（メッセージヘッダー内のフィールド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.

各制御コマンドは、これらのオペコードは0の値を持つ_opcode._、8ビットから始まる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テーブルから削除されるべきであることを他に知らせるために、1つのホストによって使用されます。 RSTに応答する以外は、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 connection is assigned with this command; the "link" field must be between 2 and 71, inclusive.

RTSコマンドは、接続を確立するために使用され、送信ソケットを含むホストへのソケットを受け取る含むホストから送信されます。このコマンドで割り当てられている接続を介してメッセージを送信するためのリンク番号、「リンク」フィールドには、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).

ALLコマンドを送信するホストのスペースカウンターを高めるために、送信ホストに受信側ホストから送信されます。接続が確立されている間のみ、このコマンドを送ることができます。又は（2 ^ 32 - 1）上記ビットカウンタ - 受信ホストが（1 2 ^ 16）上記宿主のメッセージカウンタをインクリメントが禁止されます。

   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コマンドは、送信ホストがメッセージ空間及び/又はビットスペースの割り当ての全てまたは一部を返すことを要求するために送信側ホストに受信側ホストから送信されます。各割り当ての「画分」（128thsで）どの部分を指定が返さなければなりません。接続が確立されている間のみ、このコマンドを送ることができます。

   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 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コマンドが送信されてもよいです。エラー条件が予め定義されたエラーコードを有する場合には、「コード」フィールドには、特定のエラーを特定し、データフィールドには、パラメータを与えます。他のエラーのコードフィールドがゼロであり、データフィールドは、送信者に特有です。ネットワーク制御プログラムの実装者は、彼らの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コマンドの有用性が損なわれる。したがって、サイトは、可能な場合は、着信ERRSを記録するために、そして送信サイトと連動してその原因を調査するために促しています。以下のコードが定義されています。追加のコードは、後に定義することができます。

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）誤ったパラメータが制御コマンドで発見されました。例えば、二つの受信又は二は、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.

電子。 STRまたはRTS以外の非存在しないソケットに要求（エラーコード= 4）要求がない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 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.

1. STR又はRTS以外の制御コマンドは、確立された接続の一部ではないソケット（又はリンク）を指します。 1つのRFCが送信されていたときに、このコードが使用されますが、一致したRFCはありませんでした。 RFCへの応答を待つために、それを受け取るNCPの失敗を示すことを意味します。「データ」フィールドには、エラーでコマンドが含まれています。必要な任意の充填の値はゼロです。

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ビットの符号なし2進数であると定義されます。オペコードに割り当てられた値は以下のとおりです。

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月、文書の終わりです。 ]

4. Security Considerations

4.セキュリティについての考慮事項

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

アレクサンダー・マッケンジーPMB＃4334、私書箱2428ペンサコーラ、FL 32513 USA電子メール：amckenzie3@yahoo.com

Steve Crocker 5110 Edgemoor Lane Bethesda, MD 20814 USA EMail: steve@stevecrocker.com

スティーブクロッカー5110ジエッジムーアレーンベセスダ、MD 20814 USA Eメール：steve@stevecrocker.com