rfc60.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 453 行 · 第 1/2 页

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.

Abstract

   This RFC defines a new NCP protocol that is simple enough to be
   implemented on a very small computer, yet can be extended for
   efficient operation on large timesharing machines. Because worst case
   storage requirements can be predicted, a conservative implementation
   can be freed of complicated resource allocation and storage control
   procedures. A general error recovery procedure is also defined.

Overview and Rational

   The central premise of this proposal is an insistence that all user-
   to-user connections be bi-directional. For those familiar with
   communication theory, this appears most reasonable. All communication
   requires a cyclical flow of information. To deny a simple association
   between a message and its reply makes protocol unnecessarily
   complicated and turns simple mechanisms of flow control into
   nightmares.

   It is proposed that a bi-directional connection, or duplex link, be
   identified by a pair of socket numbers, one for each end. This is
   half the number presently required. Associated with the connection
   are some number of "crates" or message containers. These crates
   travel back and forth over the link carrying network messages from
   one side to the other. Buffers are allocated at each end of the link
   to hold crates and the messages that they carry. Worst case buffer
   requirements are equal to the number of crates in circulation, or the
   "capacity" of the link.

Details

   A message buffer has four states which follow one another cyclically.
   They are:




Kalin                                                           [Page 1]

RFC 60                 A Simplified NCP Protocol            13 July 1970


   1) empty,

   2) filled with a message-laden crate to be unloaded,

   3) filled with an empty crate, and

   4) filled with a message-laden crate to be sent.

   Normally state transitions correspond to message arrival, message
   removal, message insertion and message transmission.

   For a process to be an NCP it must:

   1) be able to make initial contact with foreign hosts via the control
   link and, if necessary, delete user-to-user links left over from the
   previous system incarnation.

   2) be able to create user-to-user links.

   3) be able to interface users with these links.

   4) be able to delete user-to-user links.

   The first of the four functions shall not be discussed here except to
   point out that it contains critical races that can not be resolved
   without making assumptions about maximum message propagation delays.
   Since within the ARPA network, bounds on message turnaround time do
   not exist, the approach chosen must necessarily be tender. The other
   three functions are discussed first from the viewpoint of one
   interested in implementing a minimal NCP. Then extensions and
   improvements are proposed that are suitable for larger machines.

   Any NCP must be capable of creating a duplex link between a local
   user process and a remote one. The current protocol accomplishes this
   by queuing a potentially unbounded number of RFC's and waiting for
   the user to examine the queue to determine with whom he wishes to
   talk. There is no guarantee that the user will ever look at the queue
   and there is no way to limit the size of the queue. The overflow
   error message suggested fails in the respect because it admits that
   the RFC will only be sent again. The picture need not be this bleak.
   The following network conversation demonstrates how connections can
   be made without using queues or relying on user process attention.

   Suppose that a local user process and a remote user process wish to
   establish a new connection. The remote process asks its NCP to listen
   for a connection request and gives it the socket identifier for its
   end. Optionally it can give both socket identifiers. The user process
   at the local end asks its NCP to send a request for a duplex link



Kalin                                                           [Page 2]

RFC 60                 A Simplified NCP Protocol            13 July 1970


   (RFDL). It specifies both socket identifiers of the proposed link.
   The local NCP sends a RFDL over the control link with the following
   format:

   RFDL <my socket> <your socket> <max number buffers> <spare>

   The third argument is normally supplied by the local NCP and
   indicates the maximum number of buffers the NCP will consider
   allocating to this duplex link. If buffers are in user storage the
   count may be given by the user in a call made to the NCP.

   The RFDL is received at the remote host and the remote NCP compares
   <my socket> and <your socket> against the socket identifiers supplied
   by unmatched listens issued to it. For listens in which just a single
   identifier was given only <your socket> must match. If both socket
   identifiers were given, they both must match. If a match is found an
   acknowledgement message with the following format is sent back by the
   NCP:

   ACDL <your socket> <my socket> <number buffers> <spare>

   The <number buffers> parameter is equal to the smaller of <max number
   buffers> as specified in the RFDL and the number of message buffers
   agreeable to the remote NCP. If no match is found the error message
   returned is an ACDL in which <number buffers> equals zero. Note that
   the RFDL mechanism is similar to a RFC mechanism in which the bound
   on queue size is one and connection acceptance is done entirely by
   the NCP.

   The two varieties of a listen correspond to two modes of channel
   operation. The single parameter variety, as typified by a LOGIN
   process, is to be used by programs that will "talk with anyone who
   happens to dial their number". Screening of contacts for
   appropriateness is left to the user process. The double parameter
   listen is used by user programs who know with whom they will
   communicate and do not wish to be bothered by random RFDL's from
   other sources. Given the way in which socket name space is
   partitioned, it is impossible to get a matching RFDL from any process
   but the one intended.

   Message buffers for the connection are allocated in the remote host
   before it sends the ACDL and in the local host at the time the ACDL
   is received. The number of buffers at each end is equal to the
   <number buffers> parameter in the ACDL. The state of all remote
   buffers is "empty" and of all local buffers "filled with empty
   crate". After buffers are allocated the local user process is
   notified that it is able to start sending messages.




Kalin                                                           [Page 3]

RFC 60                 A Simplified NCP Protocol            13 July 1970


   The type of interface presented by the NCP between the user process
   and the newly created duplex link is a decision local to that host. A
   simple but complete interface would provide two calls to be made to
   the NCP. GETMESSAGE would return the next message from the link
   complete with marking, text and padding. PUTMESSAGE would take a
   message, marking and text only, and buffer it for transmission. The
   obvious logical errors would be reported.

   We suggest that message alignment be left to the user. On most
   machines it is a simple but time consuming operation. If done in the
   NCP there is no guarantee that the user will not have to readjust it
   himself. It is usually not possible to know a priori whether the text
   portion should be right adjusted to a word boundary, left adjusted to
   a word boundary, aligned to the end of the last message, or
   fragmented in some exotic way.

   Within this protocol message boundaries are used to provide storage
   allocation information. If not required by the user this information
   can be forgotten and the user interface can be made to appear as a
   bit stream. Though welcomed by purists, such a strategy may produce
   complications when attempting to synchronize both ends of a link.

   Links are deleted by removing empty crates from them and reclaiming
   the buffers allocated to the crates removed. Only buffers with crates
   in can be reclaimed; empty buffers must remain available to receive
   messages that may arrive. When no crates are left, no buffers remain,
   and the socket identifiers can be forgotten. When empty crates are
   removed, a decrement size message is sent to the foreign NCP to allow
   it to reduce its buffer allocation:

   DEC <my socket> <your socket> <number of buffers dropped>

   A reply is solicited from the foreign NCP to affirm the deletions or
   to complain of an error. Possible errors include "no such link" and
   "impossible number of buffers dropped".

   The option to close a link can be given to a user process by
   providing either of two system calls. NOMOREOUTPUT declares that no
   more messages will be sent by the local user process. All local
   buffers for the link that contain empty crates are reclaimed by the
   NCP. DEC messages are sent to the foreign NCP. As crates are emptied,
   via GETMESSAGE calls, their buffers are reclaimed too. As an
   alternative, the call KILLMESSAGE can be implemented. This call can
   be used in place of a PUTMESSAGE. Instead of filling an empty crate
   with a message to be sent, KILLMESSAGE will cause the crate to be
   reclaimed and a DEC control message sent.

   In situations where the user process has died, or for some other



Kalin                                                           [Page 4]