RFC102 Host - Description of the Host Protocol Fault Clear Committee

xiaoxiao2021-03-06  107

Organization: China Interactive Publishing Network (http://www.china-pub.com/)

RFC Document Chinese Translation Program (http://www.china-pub.com/compters/emook/aboutemook.htm)

E-mail: Ouyang@china-pub.com

Translator: Shao Yi (EPL shaoyi@163.net)

Translation time: 2001-10-11

Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but must

Keep the translation and copyright information of this document.

Network Working Group Steve Crocker, Chairman

Request for Comment: 102 AT BBN, CAMBRIDGE

NIC # 5763 22, 23 February 1971

Host - Description of the Host Protocol Fault Clear Committee

(RFC102 --- Output of the host / host protocolglitch cleaning committee)

A committee has established a committee at the Urbana Network Working Group on February 17, 1971. This committee

Will focus on the host-host protocol, which is responsible for examining the urgent needs or necessary changes.

The chairman of the committee was held by Steve Crocker, composed of another eight members:

Ray Tomlinson BBN (Tenex)

Jim White UCSB

Gary Grossman Illinois

Tom BarkAlow Lincoln (TX2)

Will Crowther BBN (IMPS)

Bob Bressler Mit (Dynamic Modeling

Doug Mckay IBM (Yorktown)

Dan Murphy BBN (Tenex)

The meeting discussed some questions. For some of these problems, members are suggested, and how to change

Again. There are still some problems, and are just a variety of options.

The Committee will immediately discuss in-depth discussions on the network group and collect feedback on its recommendations and proposals. then,

The Committee will call everyone again on March 8, 1971 to determine the final motion. Next, Steve

CROCKER is responsible for writing 2 files. According to the basis of the work steps, the network working group RFC53 documentation.

Here are the details of the recommendations:

1. The length of the ECO and ERP command should be 8 bits (BITS).

2. The length of the ERR command should be 96 bits.

3. The message data type should be removed. This mechanism is achieved by the third level protocol.

4. The "stop" mechanism should be abolished.

5. A pair of new single byte commands should be added: RST (Reset) and RRP (Reset Answer). RST should be solved

Releases the signal of all the NCP tables that clear all current entry excited by the sender host. Should also return

The RRP command indicates that the RST command has been received. The host that sends the RST command can receive the returned RST

Continue to work next after the RRP command. If there is a host, you can also return one

The RST command.

6. Although everyone suggested at the Urbana meeting, the committee still recommends retaining the original program.

Do not change.

7. The message length should be an integer byte and give the number of bytes and byte lengths in the message. The habit of the marker should be abolished and the filler is ignored.

The number of bytes in the information should consist of the message header and the subsequent 16-bit number. Byte length is taken

The 8-digit domain representation. The next section will explain two proposals for text starting points.

For the purpose of flow control, the number of bits in the message body is the product of the byte number and byte length. Message head

And other fixed formats are not.

8. Consider the problem of interrupt signal synchronization in the terminal input stream, we believe that the number of the scanner can be input to the terminal.

law. Two reasonable implementations include: Terminal input scanner can be readily read into characters quickly.

Look for interrupt characters and discard the string when the user process is entered. In addition, it is

Read characters according to the acceptable speed (or at least read space) according to user processes.

The first program guarantees the interrupt character (such as Control-C on PDP-10), but it needs

The process to be used is explained to the output stream, thus detecting whether it is too fast. Second plan avoid

No overflow problem, but does not support the transmission of the interrupt code. Note that in the first case, allocation is always along with

The terminal input interpreter is updated as soon as possible, the update of the allocation scheme is only as a result of the data accepted by the user process.

fruit.

We think that INS means inserting a special code into the input stream, and this problem is

Alternative to the third level agreement problem. Also related to create a special code inserted into the input queue

in.

This special code can be a network range, different special interrupted characters different from the active system.

symbol. The method of explaining the process is: the active process is inserted into the code in the sequence of the host interrupt, and follow the network.

Other code, and INS.

Here are a few unwell solutions:

1. Control information length

Compared with other specifications, the control information should be an 8-digit integer, and the length of the information should be in byte count.

The position is marked. Moreover, the control command cannot be disconnected.

This issue is not resolved for the length of the control information. There are two options:

a) None Special restrictions (1000 bytes)

b) 120 bytes

2. Message format

Members unanimously agree to remove markers and mark the length of the text in bytes and byte lengths. About data

The starting point problem of one byte is not determined. Two options are:

a) Let the data first bytes start with 72-bit message heads, bytes, bytes, and interval. then

The message format is shown below:

<------------ 16 ------------>

__________________________

| | |

| _ _ _ _ News head _ _ _ _ |

| | |

| __________________________ |

| | |

| Number of bytes |

| __________________________ |

| | | | |

Byte length ----- | ----> |

| ____________ | _____________ |

| | | | |

| |? ----------------- | - Data first byte starting point

| ____________ | _____________ |

| | |

| | |

b) Use the two-way physical transmission scheme proposed using the network working group RFC67. Normally

When the message, the host should send a message header, as well as bytes, byte length, and terminate the transfer. Second This transmission is a message data.

3. distribution

Considering the allocation mechanisms included in the all, gvb, and ret commands, we give two options:

a) Keep the original solution unchanged.

b) Change the stream control algorithm to track the number of record messages and bits. ALL, GVB and RET life

There are two digits. The all command assigns a message cap and a bit limit. GVB command

Two sections of components. The RET command returns to the message body and returns a bit. Send a message

NCP minus the message number 1 and subtracts the number of message texts. The transmitted NCP cannot make

Its counter is negative. The message counter should be 16 digits.

[This RFC document is from Gottfried Janik in February 1998]

[Component as a machine readable form to entered RFC online file]

RFC102 --- Output of the host / host protocolglitch cleaning committee

Host - Description of the Host Protocol Fault Clear Committee

1

RFC Document Chinese Translation Program

转载请注明原文地址:https://www.9cbs.com/read-126461.html

New Post(0)