Independent Submission A. McKenzie
Request for Comments: 6529 S. Crocker
Category: Historic April 2012
ISSN: 2070-1721
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.
本文件复制了ARPA网络工作组在1969年、1970年和1971年期间开发的主机/主机协议。它描述了用于管理驻留在独立主机上的进程之间的通信的协议。它解决了在单个硬件接口上多路复用多个通信流（包括寻址、流控制、连接建立/解除和其他信令）的问题。从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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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 ....................................................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年创建，由加州大学洛杉矶分校的研究生Steve Crocker担任主席。许多数量少于72个的RFC，加上RFC 102、107、111、124、132、154和179，处理了该协议的制定。Crocker于1970年8月3日发布了定义该协议的第一份官方文件，称为“第1号主机协议文件”（参见RFC 65中的引文），该文件基于Crocker、Postel、Newkirk和Kraley的RFC 54。如RFC 102所述，1号文件的修订于1971年2月中旬开始。尽管麦肯齐被列为1972年1月文件的作者，该文件取代了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.
在发布“第1号主机协议文件”时，未向其提供RFC编号，因为该文件不被视为“征求意见书”，而是作为实施标准。这是斯坦福研究所（SRI）网络信息中心（NIC）作为一套单独文件维护的一套标准之一。此处复制的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仅限于使用单一字体，因此我们尝试使用所有大写字母或双下划线表示粗体，并在单词周围使用下划线代替空格表示斜体。生成的文档更难阅读，但保留了原始文档的重点。当然，页码已更改，我们希望已正确修改所有页码。原始文件中有三个脚注，我们已将其移至文本中，用缩进和方括号隔开。原始文档的.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取代。在本文档中，该协议被称为第二层（或“级别”）协议，而在当前的著作中，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网络协议中的一个；所有协议规范都收集在文件“当前网络协议”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页）-讨论排队和不排队RFC的影响（第14页）-强烈建议记录接收到的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
Alex McKenzie Bolt Beranek and Newman Inc.马萨诸塞州剑桥莫尔顿街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
乔恩PASTEL加州大学洛杉矶分校计算机科学系3732博尔特霍尔洛杉矶，加利福尼亚90024（213）325-363
TABLE OF CONTENTS
目录
I. INTRODUCTION..................................................8
An overview of the multi-leveled protocol structure in the ARPA
Network.
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.
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.
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
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.
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
Message Format....................................23
Link Assignment...................................25
Control Messages..................................25
Control Commands..................................25
Opcode Assignment.................................31
Control Command Summary...........................31
I. INTRODUCTION
一、导言
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网络为地理上分离的计算机（称为主机）提供相互通信的能力。主机通常在类型、速度、字长、操作系统等方面彼此不同。每台主机通过称为“接口”、“消息”、“处理器”（IMP）的本地小型计算机连接到网络中。通过互连这些IMP形成完整的网络，所有IMP实际上都是相同的，通过电话公司提供的宽带通信线路。每个IMP被编程为存储消息并将消息转发给网络中的相邻IMP。在典型操作期间，主机将消息传递给其本地IMP；此消息的前32位包括目标主机的“网络地址”。消息通过网络从一个IMP传递到另一个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）第1822号报告中。这些规范通常称为“第一级协议”或主机/IMP协议。但是，该协议本身不足以指定在两个不同主机上运行的进程之间的有意义的通信。相反，这些过程必须在启动通信的方法、传输数据的解释等方面有一些一致性。尽管有可能由对通信感兴趣的每对主机（或进程）达成此类协议，但为了最小化网络范围通信所需的实现量，需要更一般的安排。因此，主机组织成立了一个网络工作组（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协议。下一层指定建立通信路径、管理通信路径两端的缓冲区空间以及提供“中断”通信路径的方法。该协议将由所有高级协议使用，称为第二级协议或主机/主机协议。（值得注意的是，尽管IMP子网提供了“消息”交换的能力，但主机/主机协议基于“线路”交换的概念。目前开发或预期的其他协议层示例包括：
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) 一种(初始)连接(ICP)协议(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) 一种远程通信网络（TELNET）协议，用于将任意键盘打印机终端“映射”到网络虚拟终端（NVT），以促进一个主机站点的终端用户与另一个站点的终端服务进程之间的通信，该站点“期望”连接到（本地）终端终端在逻辑上与实际使用的（远程）终端不同。TELNET协议规定使用ICP在终端用户和终端服务进程之间建立通信路径。
3) A _Data_Transfer_ protocol to specify standard methods of formatting data for shipment through the network.
3) 一种_Data _Transfer u协议，用于指定格式化通过网络装运的数据的标准方法。
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 u协议，用于指定交换图形显示信息的方式。
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) 一种远程作业服务（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
二,。传播概念
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.
尽管在硬件或操作系统中主机之间几乎没有一致性，但多道程序设计的概念主导了大多数系统。这些主机可以同时支持多个用户，每个用户运行一个或多个进程。这些进程中的许多进程可能希望同时使用网络，因此主机/主机协议的基本要求是通过网络提供进程到进程的通信。由于第一级协议只考虑主机，并且由于主机内执行的几个进程通常是独立的，因此第二级协议必须提供更丰富的寻址结构。
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.
影响主机/主机协议设计的另一个因素是期望典型的进程间通信不是基于单个消息，而是基于一系列消息。一个例子是将大量信息（如数据库）从一个进程发送到另一个进程。另一个例子是两个进程之间的交互式对话，其中包含许多交换。
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.
连接是链接的扩展。一个连接连接两个进程，这样一个进程的输出被输入到另一个进程。连接被定义为单纯形（即单向），因此，如果一对进程要在两个方向上反转，则需要两个连接。
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.
主机内的进程被设想为通过驻留在该主机中的网络控制程序（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.
为了完成其任务，一台主机的NCP必须与其他主机的NCP通信。为此，每对主机之间的特定链路被指定为“控制链路”。通过控制链路传输的消息称为“控制消息”，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.]
[*请注意，在编号为1822的BBN报告中，非零类型的消息称为控制消息，用于控制主机与其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（而不是每个传输进程）应负责将进程间通信分割为网络消息。因此，第二级协议的一个原则是接收进程不能从消息边界推断出任何意义_此原则的唯一例外是控制消息中的消息，每个消息必须包含控制命令的整数_
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 _大小达成一致。然后，通过连接发送的每条消息必须包含此大小的整数字节。因此，连接中涉及的一对进程可以选择相互方便的字节大小，例如，它们的主机字长度的最小公倍数。需要注意的是，选择字节大小的能力必须对连接中涉及的进程可用；禁止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位被称为_消息_头。u选择72位的长度，因为大多数主机可以方便地使用8位数据单元，或者字长为18或36位；72是这些长度中最不常见的倍数。因此，为消息头选择的长度应该减少许多主机的位移位问题。除了前导，消息头还包括一个字段，该字段给出消息中使用的字节大小，一个字段给出消息中的字节数，以及“填充”字段。报文头的格式在第四节中有详细说明。
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。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 uu，也可以是_send u socket，uu，并通过其低位（0=接收；1=发送）进行标记。此属性称为套接字的_性别。_连接两端的套接字必须是异性。除性别外，第二级协议对主机内套接字编号的分配没有任何限制。
III. NCP FUNCTIONS
三、 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的功能是建立连接、终止连接、控制流、传输中断和响应测试查询。本节将解释这些功能，并根据需要介绍控制命令。在第四节中，所有控制命令的格式一起介绍。
Connection Establishment
========================
Connection Establishment
========================
The commands used to establish a connection are STR (sender-to-receiver) and RTS (receiver- to-sender).
用于建立连接的命令有STR（发送方到接收方）和RTS（接收方到发送方）。
8* 32 32 8
+----------------------------------------------+
| STR | send socket | receive socket | size |
+----------------------------------------------+
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 |
+----------------------------------------------+
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命令从潜在接收方发送到潜在发送方。send socket字段指定预期发件人的本地套接字；receive socket（接收套接字）字段为预期接收者命名一个本地套接字。在STR命令中，“size”字段包含一个无符号二进制数（范围为1到255；禁止为零），指定用于连接上所有消息的字节大小。在RTS命令中，“链路”字段指定链路编号；连接上的所有消息必须通过此号码指定的链接发送。这两个命令称为连接请求（RFCs）。如果接收套接字字段匹配而发送套接字字段匹配，则STR和RTS匹配。当交换了一对匹配的RFC时，就会建立连接_禁止主机与任何本地套接字建立多于一个的连接_
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.
对于特定连接，包含发送套接字的主机称为“发送主机”，包含接收套接字的主机称为“接收主机”。主机可以将其一个接收套接字连接到其一个发送套接字，从而成为该连接的发送主机和接收主机。
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命令用于请求和接受建立连接，因此两个协作进程中的任何一个都可以启动建立连接。因此，可以使用内置的连接启动操作创建一系列进程，并且该系列中的进程可以按任意顺序启动（在不同的主机中），前提是相关主机执行适当的排队（见下文）。
_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规定生命周期。允许主机将传入的RFC排队并在任意长的时间内保留响应，或者，如果没有匹配的RFC未完成，则可以立即拒绝请求（请参见下面的连接终止）。例如，对于NCP来说，将引用某个当前未使用的套接字的RFC排队，直到本地进程控制该套接字编号并通知NCP接受或拒绝该请求，这可能是合理的。当然，发送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;
对于上述问题，最合理的解决方案可能是，每个NCP为在自己的主机上运行的进程提供两个尝试启动连接的选项。第一个选项允许进程将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。第二个选项允许进程告诉其自己的NCP从某个远程套接字“侦听”某个RFC到某个指定的本地套接字（进程还可以指定它希望与之通信的特定远程套接字和/或主机），并在RFC到达时接受RFC（即返回匹配的RFC）。请注意，这也涉及排队（对“侦听”请求），但这是内部排队，容易受到本地主机的合理管理。如果此实现可用，则两个协作进程中的一个进程可以“侦听”，而另一个进程导致一系列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.
_协议的目的是，每个NCP应提供上述“侦听”选项或实质性排队设施。然而，这不是协议的绝对要求。
Connection Termination
======================
Connection Termination
======================
The command used to terminate a connection is CLS (close).
用于终止连接的命令是CLS（close）。
8 32 32
+-----+-------------+-------------+
| CLS | my socket | your socket |
+-----+-------------+-------------+
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命令发送方的本地套接字。“yoursocket”字段包含CLS命令接收器的本地套接字_在连接结束之前，每一方都必须发送和接收CLS命令，并且插座可以自由地参与其他连接_
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.
在连接终止开始之前，不需要建立连接（即交换两个RFC）。例如，如果主机希望拒绝连接请求，它将发回CLS而不是匹配的RFC。拒绝主机然后通过返回CLS等待发起主机确认拒绝。类似地，如果主机希望中止其未完成的连接请求，则会发送CLS命令。外国主机有义务用自己的CLS确认CLS。请注意，即使从未建立连接，也必须先交换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命令指示不再通过连接发送消息_如果在连接上有一条消息正在传输，则此命令不得发送。接收方发送的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，以便外部主机可以清除其表。但是，没有规定必须确认的时间和期限_
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向A发送CLS以拒绝连接。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发送一个RFC，后跟一个CLS，如示例1所示。然而，在这种情况下，当a发送其CLS时，B向a发送匹配的RFC。主机A可能“相信”RFC是（在B方面）建立新连接的尝试，或者可能理解竞争条件；无论哪种情况，它都可以丢弃RFC，因为它的套接字尚未空闲。主机B将“相信”CLS正在断开已建立的连接，但结果是正确的，因为匹配的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。这个解决方案有两个困难。首先，所涉及的套接字可能是“稀缺资源”，如初始连接协议（参见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.
有时建议的第二种可能性是，等待匹配CLS命令的主机（主机A）向有问题的主机（主机B）发送RST（见第20页），从而允许在两端重新初始化所有表。这对于主机A上碰巧通过网络连接在主机B上执行有用工作的任何用户来说都是相当不满意的，因为这些连接也会被RST破坏。
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最终到达，则第二个连接可能会关闭。然而，只有当一台主机以两种方式违反协议时，才会出现这种情况；首先是无法快速响应传入的CLS，其次是允许建立一个连接，该连接涉及它认为已经在使用的套接字。有人建议网络采用一些标准的超时时间，但NWG无法达到一个既短到有用又长到每个主机都能接受的时间。当前使用的超时时间似乎介于大约一分钟到大约五分钟之间_必须强调的是，尽管所有的超时时间都比较常见、合理安全、非常有用，但它们都违反了协议，因为它们的使用会导致连接的模糊性_
Flow Control
============
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).
与每个连接关联的是一个_消息_计数器uu和一个_位u计数器。u每个计数器在建立连接时初始化为零，并通过从接收主机发送的分配（所有）控制命令增加，如下所述。发送消息时，发送主机的NCP从消息计数器中减去1，并从位计数器中减去_text_length_（定义见下文）。如果任何一个计数器将减至零以下，则禁止发送方发送。发送主机还可以在接收到来自接收主机的回送（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).
用于增加发送方位计数器和消息计数器的控制命令为ALL（allocate）。
8 8 16 32
+------------------------------------+
| ALL | link | msg space | bit space |
+------------------------------------+
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 space”字段和“bit space”字段定义为无符号二进制整数，指定发送方消息计数器和位计数器（分别）的递增量。禁止接收方将发送方计数器的增量增加到（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（返回）。
8 8 8 8
+----------------------+
| GVB | link | fm | fb |
+----------------------+
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分之一）。如果任何分数等于或大于一，则必须返回相应分配的所有。之所以使用分数，是因为在消息传输过程中，发送方和接收方可能不会在每个时间点就实际分配达成一致。
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命令后，发送主机必须返回消息的请求部分和位空间分配。（禁止发送主机自动返回部分消息和位空间分配。）执行此功能的控制命令为RET（返回）。
[*In particular, fractional returns must be rounded up, not truncated.]
[*特别是，分数回报必须向上舍入，而不是截断。]
8 8 16 32
+------------------------------------+
| RET | link | msg space | bit space |
+------------------------------------+
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 space”字段和“bit space”字段定义为无符号二进制整数，指定发送方的消息计数器和位计数器（分别）因RET活动而减少的量（即返回的消息和位空间分配量）。NCP必须以RET“快速”回答GVB；但是，没有规定必须发送应答RET的时间段。
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
==========
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 |
+------------+
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 |
+------------+
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
============
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（echo）。
8 8
+------------+
| ECO | data |
+------------+
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的主机选择的任何位配置。收到ECO命令后，NCP必须通过ERP（回送回复）命令将数据返回给发送方进行响应。
8 8
+------------+
| ERP | data |
+------------+
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命令。但是，在收到ECO后，没有规定必须归还ERP的期限。当未收到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的“答复”：来自本地IMP的信息，表明ECO已被网络丢弃（例如，IMP/主机消息类型7-目的地死亡）、ERP、RST或RRP（见下文）。
Reinitialization
================
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错误或其他因素，两个NCP之间的通信会中断。任何此类中断的一个可能影响可能是，两个相关NCP都无法确保其存储的与另一主机的连接相关的信息与另一主机的NCP存储的信息相匹配。在这种情况下，NCP可能希望重新初始化其表，并要求其他主机也这样做；为此，协议提供了一对控制命令RST（复位）和RRP（复位回复）。
8
+-----+
| RST |
+-----+
8
+-----+
| RST |
+-----+
8
+-----+
| RRP |
+-----+
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的主机通信而产生的任何条目的信号。发送RST的主机同样应清除其NCP表中与发送RST的主机通信产生的任何条目。接收RST的主机应通过返回RRP来确认接收_一旦第一个主机向第二个主机发送了第一个主机，第一个主机就没有义务与第二个主机通信（除了响应第一个主机），直到第二个主机返回RRP。事实上，为了避免同步错误，第一个主机不应该与第二个主机通信，直到第二个主机应答。当然，如果IMP子网响应包含RST的控制消息返回“目的地死”（类型7）消息，则不应期望RRP。如果两个NCP决定几乎同时发送RST，则每个主机将收到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
一些主机可能会选择在RST“出现”时向整个网络“广播”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）消息。但是，没有主机必须发送一个RST命令_
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构成对发送到该主机的所有RRT的“应答”，并且应该丢弃从该主机到达的任何其他RRP。
IV. DECLARATIVE SPECIFICATIONS
四、 声明性规范
Message Format
==============
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前导-此字段的内容必须根据编号为1822的BBN报告中包含的规范构造。
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----------->|
|<---------------------------32 bits--------------------------->|
|<----8 bits--->|<----8 bits--->|<-----------16 bits----------->|
+---------------------------------------------------------------+
| |
| LEADER |
| |
+---------------------------------------------------------------|
| | | |
| FIELD M1 | FIELD S | FIELD C |
| | | |
+---------------+---------------+-------------------------------+
| | ^ |
| FIELD M2 | | |
| | | |
+---------------+ | |
| | |
| | |
| | |
| | |
| TEXT |
| | |
| | |
| | |
| | |
| | +--------------------+
| | | |
| | | FIELD M3 |
| V | |
+-----------------------------------+------+--------------------+
| |
| 10-----------------0 |<-------PADDING
| |
+-----------------------------------+
+---------------------------------------------------------------+
| |
| LEADER |
| |
+---------------------------------------------------------------|
| | | |
| FIELD M1 | FIELD S | FIELD C |
| | | |
+---------------+---------------+-------------------------------+
| | ^ |
| FIELD M2 | | |
| | | |
+---------------+ | |
| | |
| | |
| | |
| | |
| TEXT |
| | |
| | |
| | |
| | |
| | +--------------------+
| | | |
| | | FIELD M3 |
| V | |
+-----------------------------------+------+--------------------+
| |
| 10-----------------0 |<-------PADDING
| |
+-----------------------------------+
Figure 1
========
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
===============
Link Assignment
===============
Links are assigned as follows:
链接分配如下：
Link number Assignment
=========== ==========
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
================
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
================
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位操作码开始。这些操作码的值为0、1、。。。允许在收到时查找表。私有实验协议应使用255、254等操作码进行测试。。。第三节对大多数控制命令进行了更全面的解释。
NOP - No operation
==================
NOP - No operation
==================
8
+-----+
| NOP |
+-----+
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
===========
RST - Reset
===========
8
+-----+
| RST |
+-----+
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命令通知另一台主机，应从接收RST的主机的NCP表中清除有关两台主机之间先前存在的连接（包括部分终止的连接）的所有信息。除响应RST外，发送RST的主机无义务与另一主机进一步通信，直到收到RRP响应。
RRP - Reset reply
=================
RRP - Reset reply
=================
8
+-----+
| RRP |
+-----+
8
+-----+
| RRP |
+-----+
The RRP command must be sent in reply to an RST command.
必须发送RRP命令以响应RST命令。
RTS - Request connection, receiver to sender
============================================
RTS - Request connection, receiver to sender
============================================
8 32 32 8
+----------------------------------------------+
| RTS | receive socket | send socket | link |
+----------------------------------------------+
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之间（含2和71）。
STR - Request connection, sender to receiver
============================================
STR - Request connection, sender to receiver
============================================
8 32 32 8
+----------------------------------------------+
| STR | send socket | receive socket | size |
+----------------------------------------------+
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之间（包括1和255）。
CLS - Close
===========
CLS - Close
===========
8 32 32
+-----+-------------+-------------+
| CLS | my socket | your socket |
+-----+-------------+-------------+
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
==============
ALL - Allocate
==============
8 8 16 32
+------------------------------------+
| ALL | link | msg space | bit space |
+------------------------------------+
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^16-1）以上或位计数器增加到（2^32-1）以上。
GVB - Give back
===============
GVB - Give back
===============
8 8 8 8
+----------------------+
| GVB | link | fm | fb |
+----------------------+
^ ^
| +--- bit fraction
+-------- message fraction
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分之一）。此命令只能在建立连接时发送。
RET - Return
============
RET - Return
============
8 8 16 32
+------------------------------------+
| RET | link | msg space | bit space |
+------------------------------------+
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
===========================
INR - Interrupt by receiver
===========================
8 8
+------------+
| INR | link |
+------------+
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
=========================
INS - Interrupt by sender
=========================
8 8
+------------+
| INS | link |
+------------+
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
==================
ECO - Echo request
==================
8 8
+------------+
| ECO | data |
+------------+
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
================
ERP - Echo reply
================
8 8
+------------+
| ERP | data |
+------------+
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
====================
ERR - Error detected
====================
8 8 80
+-----+------+---------------------------- ~ -------------+
| ERR | code | data |
+-----+------+---------------------------- ~ -------------+
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命令。如果错误条件具有预定义的错误代码，“代码”字段指定特定错误，数据字段给出参数。其他
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命令的有用性就会受到损害。因此，如果可能，敦促站点记录传入错误，并与发送站点一起调查其原因。定义了以下代码。以后可能会定义其他代码。
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个字节，则需要填充；填充的值为零。
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（含）之外的链路号；包含空间分配过大的ALL。“数据”字段包含错误的命令；所需的任何填充值均为零。
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）有两种情况：
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以外的控制命令指的是不属于已建立连接的套接字（或链接）。当传输了一个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. 通过当前未用于任何连接的链接接收到消息。“数据”字段的内容是消息头，后跟前八位文本（如果有）或零。
Opcode Assignment
=================
Opcode Assignment
=================
Opcodes are defined to be eight-bit unsigned binary numbers. The values assigned to opcodes are:
操作码定义为八位无符号二进制数。分配给操作码的值为：
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
=======================
Control Command Summary
=======================
8
+-----+
| NOP |
+-----+
8
+-----+
| NOP |
+-----+
8 32 32 8
+----------------------------------------------+
| RTS | receive socket | send socket | link |
+----------------------------------------------+
8 32 32 8
+----------------------------------------------+
| RTS | receive socket | send socket | link |
+----------------------------------------------+
8 32 32 8
+----------------------------------------------+
| STR | send socket | receive socket | size |
+----------------------------------------------+
8 32 32 8
+----------------------------------------------+
| STR | send socket | receive socket | size |
+----------------------------------------------+
8 32 32
+-----+-------------+-------------+
| CLS | my socket | your socket |
+-----+-------------+-------------+
8 32 32
+-----+-------------+-------------+
| CLS | my socket | your socket |
+-----+-------------+-------------+
8 8 16 32
+------------------------------------+
| ALL | link | msg space | bit space |
+------------------------------------+
8 8 16 32
+------------------------------------+
| ALL | link | msg space | bit space |
+------------------------------------+
8 8 8 8
+----------------------+
| GVB | link | fm | fb |
+----------------------+
8 8 8 8
+----------------------+
| GVB | link | fm | fb |
+----------------------+
8 8 16 32
+------------------------------------+
| RET | link | msg space | bit space |
+------------------------------------+
8 8 16 32
+------------------------------------+
| RET | link | msg space | bit space |
+------------------------------------+
8 8
+------------+
| INR | link |
+------------+
8 8
+------------+
| INR | link |
+------------+
8 8
+------------+
| INS | link |
+------------+
8 8
+------------+
| INS | link |
+------------+
8 8
+------------+
| ECO | data |
+------------+
8 8
+------------+
| ECO | data |
+------------+
8 8
+------------+
| ERP | data |
+------------+
8 8
+------------+
| ERP | data |
+------------+
8 8 80
+-----+------+---------------------------- ~ -------------+
| ERR | code | data |
+-----+------+---------------------------- ~ -------------+
8 8 80
+-----+------+---------------------------- ~ -------------+
| ERR | code | data |
+-----+------+---------------------------- ~ -------------+
8
+-----+
| RST |
+-----+
8
+-----+
| RST |
+-----+
8
+-----+
| RRP |
+-----+
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，美国佛罗里达州彭萨科拉市邮政信箱2428号32513电子邮件：amckenzie3@yahoo.com
Steve Crocker 5110 Edgemoor Lane Bethesda, MD 20814 USA EMail: steve@stevecrocker.com
Steve Crocker 5110 Edgemoor Lane Bethesda，马里兰州20814美国电子邮件：steve@stevecrocker.com