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: Liang Zhengqiang (Zinux LPOO@163.com)
Translation time: 2002-3-2
Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but the translation and copyright information of this document must be retained.
Network Working Group R. Kalin
Request for Comments: 60 mit
Category: Experimental 13 July 1970
A Simplified NCP Protocol
STATUS OF this MEMO
This Memo Defines An Experimental Protocol for the Internet
Community. this Memo Does Not Specify An Internet Standard of Any
Kind. Discussion and Suggestions for Improvement Are Requested.
Distribution of this Memo is unlimited.
Summary
This RFC defines a new NCP protocol, which is very simple, so it can be implemented on a small computer. However, the protocol can be expanded and efficiently running on a large minute machine. Because in the worst case, storage requirements can be foreseen, so a conservative implementation method of the protocol is to consider complex resource allocation and storage control processes. The protocol defines a general error recovery process.
Summary and review
This protocol has a very important assumption that insists that all users to the user is two-way. This is the most reasonable for those who are familiar with the theory of communications. All communications require constant looping information. Separate the message and its corresponding response information, which makes the agreement unnecessary complex, and the simple stream control mechanism will become abnormal.
It is recommended to distinguish between a two-way connection or call a two-way link with a set of interfaces, each of which represents one end. This is half of the number of current needs. About the connection is some "box" or a message container. These boxes carry network messages from one end from one end to the other end in the link and constantly repeatedly. Each end of the link is assigned a buffer to save the box and the news thereof. In the worst case, the number of buffers required is equal to the number of boxes flowing in the network, that is, the "capacity" of the link is consistent.
detail
One message buffer has four states of looping, they are:
1) Empty state,
2) Full of a box full of messages
3) full of empty boxes, and
4) Full of a box full of messages
The mutual conversion of the state corresponds to the arrival of the message, the removal of the message, the insertion of the message, and the transmission of the message.
An NCP must meet the following conditions:
1) The initial connection can be made by controlling the link and the external host, and the link to which the previous system established is deleted when necessary.
2) Creating a user to the user's link.
3) Can interact with the user through these links.
4) Ability to delete the link to the user to the user.
The first one in the above four functions should not be discussed here, but it must be pointed out that if the assumption of the maximum message transfer delay is not, the key issue of this feature cannot be resolved. Since there is no message in the ARPA network, the method of selecting does not have high reliability. From the achievement of a minimized NCP perspective, the other three functions will be discussed below. If you are used for larger machines, further expansion and improvement are required. Any NCP must be able to build a duplex link between local user processes and remote processes. Current protocols are waiting for the user check queue to achieve his hopes and who communicates by using any RFC number plum. This guarantees that the user will not look at the queue, and there is no way to limit the size of the queue. Overflow error messages will fail because it acknowledges that RFC will only be sent once. However, the situation is not so bad. The following network session tells us how to connect without queues and not relying on user processes.
Suppose a local process and a remote process wish to create a new connection. The remote process queries its NCP to listen to the connection request and tell its host. It can give two sets of socket numbers casually. The local process will require its NCP to send a dual-way link request (RFDL). The two socket numbers of the link are determined.
The local NCP sends a RFDL by the control link according to the following format:
RFDL
The third parameter is usually given by local NCP, which indicates the maximum number of buffers that NCP will be allocated for this duplex link. If the buffer is in the user memory, the number can be given by the user's NCP call.
RFDL is received at the remote host, and the remote NCP will compare
ACDL
The value of parameter
Variations of two listening methods correspond to two channel operating modes. Single parameter variants will be used for programs for "communication with any online host", typically like the Login process. As for the communication, it is determined by the user process. Double-parameter variants are used to interrupted the user knows that they will communicate and do not want to be interrupted by the random RFDL of other hosts. If the socket name space is divided into several parts, only the matching RFDL can only be obtained from a specific process.
The remote host allocates the message buffer for the connection before sending ACDL, and the local host assigns buffers when receiving ACDL. The number of buffers per end is equal to the parameter
The user process involved in the NCP and the interface type between the new duplex link is determined by the respective host. A simple and complete interface can provide two NCP calls. GetMessage will return next messages from the link, including tag, text, and padding bytes. PutMessage will take a message that includes only tags and text and buffers it ready to send. If there is a significant logic error, it will be reported. We recommend left the responsibility of the message to the user. This is a simple but time consuming operation on most machines. If implemented in NCP, you cannot guarantee that users do not need to re-adjust it. Experience is unlikely to know that the text should be adjusted to the left, or right to adjust the word alignment, or to the last message, or use a special way to slide the message.
The message boundary will be used to provide storage allocation information in this Agreement. If the user does not use this information, then it can be ignored it, the user interface can be seen as a bit stream. Although this strategy is welcomed by pureists, this strategy will make things complicated when trying to synchronize the link.
A link can be deleted by deleting empty boxes from the link and the buffer allocated to these empty boxes is recovered. Only those buffers containing the box can be recycled, and the empty buffer must be reserved to receive the message from which to receive. When all the boxes are deleted, the buffer no longer exists, and the socket number can be ignored. When the empty box is deleted, a streamlined message will be sent to the external NCP to reduce the amount of storage assigned to the buffer. The format of this message is as follows:
Dec
The external NCP then is required to send an answer to determine the correct execution of the delete operation or to inform the error. The error may be "there is no such link" or "the number of buffers deleted".
There are two system calls that can be selected to close a link. Nomoreoutput will claim that the local user process will not send a message. All local buffers with links with empty boxes are reclaimed by NCP. The DEC message will be sent to the external NCP. When the box is empty, it also reclaims their buffer through the getMessage. Another system call is KillMessAg. This call can be used instead of PUTMESSAGE. KillMessAg will recycle empty boxes and send a DEC control message instead of filling the empty box with a message to be sent.
Emergency measures must be taken in the case where the user process is deadlock or other unable to turn off the link. In these cases, we define the ABEND control message:
Abnd
After sending an abend, the NCP that sends this message will start to turn off the link. All buffers including input information will be turned off. For these buffers, the previous air buffer will send a DEC message to the external NCP. If the message arrives in the link, these messages are destroyed and a DEC will be sent. Any ABEND message received from the link will be ignored.
When the remote NCP receives the ABEND message, it stops sending messages to the link and refuses to accept new messages from its user process. Air buffer is recycled. Waiting for the accepted output message being destroyed, the corresponding buffer is also reclaimed. As long as the user process agrees, the input information will be injected into the user process. When the input is agreed to receive, its buffer is also required to return. Submitted DEC messages will remove recycled buffer. When the user process is no longer input, the input message will be destroyed, and its buffer will be reclaimed. In fact, all buffers per end in the link will eventually be reclaimed. This is the connection can be turned off, and the corresponding socket number can also be reassigned without confusion.
Under this proposed protocol configuration, the above four functions include all the functions necessary to have a network NCP. If only the buffer allocation work only after a buffer space is released, then there will be "overflow" error, and it is not necessary to add more restrictions to the message stream. For each user, there is definitely a buffer space to accept the message. For any user, there is definitely a buffer to receive a message. All control messages do not require additional storage. Local management programs prevent excessive listening of a user process. When many unfinished connections are present, it will cause storage space to use very inefficient. A price of the simple encoding is a waste of 50% buffer space. On a large host, it can be proved to achieve the following NCP expansion. If a more complex stream control process is used, an NCP may allocate more buffer spaces that exist in actual, and will not have problems. Other expansion enables the compression of the message, improvement in throughput, and transparent error recovery mechanism.
Because some expansion requires collaboration of external hosts, and assumes that these hosts do not only achieve minimization NCP, some people advocate using a query control message to see what extension of external hosts achieved. A response to an INQ is a control message that defines the host specification. If a "undefined error" is returned, the external host will be defame that only one minimized NCP is implemented.
A simple expansion is to define a control message instead of the user RFNM message. One user RFNM is an empty text message, such as when the file is transmitted as a response message via the duplex link. They are inefficient because they bind one item with the IMP link allocation table while reducing the throughput of the network. A more efficient solution is to send a special message by controlling the link. With this way, a short message can replace several user messages.
Urfnm
Since the control link is at the same time at the same time, when the answering link has other messages to be sent, the URFNM cannot be replaced by the user RFNM. Otherwise, the message will become disordered, and the transparency of users will lose.
The throughput can be increased by adding an additional amount of a box on a duplex link. This is or is done by the user, or is responsible by NCP.
Inc
The external host responds to this request via INCR.
InCr
If the external NCP does not meet additional buffering requirements, the
The
If the NCP retains a copy of the user message sent on the network until an error automatic recovery process can be implemented until it receives the answer message. Since the link bandwidth is always known, NCP can know if there is a message in this link in transmission. This is achieved by sending a STOP message to the outside NCP:
Stop
The STOP message tells the external NCP to temporarily stop sending messages on a specific link. Unlike Cease-on-Link, how much message sent before the entry of STOP messages is not guaranteed. When the local NCP receives the message, it will send a query message: Linq
The response message gives the number of boxes in the external end of the link. The LINQ message is constantly being sent repeatedly until the number of boxes in the external terminal is equal to the sum of the local boxes and the link bandwidth. There is no transmission message in this moment, and both ends of the link have been synchronized. Refer to this synchronization point, you can identify each message. For example, local NCP can send a control message to request all messages after the third message. External NCP can recognize specific messages and resend. Once all errors are restored, a START control message similar to the STOP is sent to the external NCP, and the normal operation is recovered. The entire error recovery process can be accepted and sent to the user process transparent.
It is hoped that the largest host is not affected by the worst case of storage allocation. So they would rather allocate buffering than their actual buffer quantities, and to ensure that most of the time can work properly based on probability. As long as the external host is transparent, then this method is very good. As long as the NCP itself is not captured, the protocol is allowing NCP to report its storage allocation. In the case of detection, it is necessary to achieve the following control mechanisms. These mechanisms are listed in the order of power, the more power, the more powerful.
a) Do not send any user RFNM messages or other short messages. It is a good attempt to use longer messages to reduce buffering needs.
b) Try not to receive any new messages from IMP. A local process that is trying to send a message is blocked.
c) Send DEC messages to release buffer space. Buffers assigned to RFDL do not exceed one, but also reject the INC message.
d) If the message waits for user processing, it is forged an error in the message. This method can only be employed only if the error recovery mechanism is implemented on the host of the send message. This method will release the space of the buffer to allow the user to recover. The final measure is recognized as the final way of rescue, but it should have enough ability to control any emergency.
The authors hopes that the above agreements can become an attractive implementation of RFC 54 and its accessories. Although the agreement is late, its implementation does not require much effort. It is simple enough to achieve it very quickly. If used, most sites currently achieve intelligent communication before the end of summer.
References
[1] CROCKER, S.D., Postel, J., Newkirk, J. And Kraley, M., "OFFICIAL
Protocol Proffering, RFC 54, June 1970.
Author's address
Richard Kalin
MIT Lincoln Laboratory
[This RFC WAS PUT INTO MACHINE READABLE FORM for Entry]
[INTO THE ONLINE RFC Archives By Ian Redfern 3/97]
