rfc60.txt

RFC技术文档 从0000－05

RFC 60                 A Simplified NCP Protocol            13 July 1970


   reason can not close the link, more drastic measures must be taken.
   For these situations, the ABEND control message is defined:

   ABEND <my socket> <your socket>

   After sending an ABEND the issuing NCP starts to close the link. All
   buffers containing input are destroyed. A DEC is issued for these and
   the previously empty buffers. If messages arrive on the link, they
   are destroyed and a DEC is issued. Any ABEND received for the link is
   ignored.

   When the remote NCP receives the ABEND, it stops sending messages
   over the link and refuses new messages from the user process at its
   end. Empty buffers are reclaimed. Pending output messages are
   destroyed and their buffers reclaimed. Input messages are fed to the
   user process as long as it will accept them. Buffers are reclaimed as
   input is accepted. DEC's are issued to cover all buffers reclaimed.
   When the user process will take no more input, input messages are
   destroyed and their buffers reclaimed. Eventually all buffers will be
   reclaimed at both ends of the link. At such time the connection can
   be considered closed and the socket numbers used can be reassigned
   without ambiguity.

   Under this proposed protocol the above four functions constitute all
   that must be part of a network NCP. If buffers are allocated only
   when free ones exist there can be no "overflow" errors nor is there
   any need to place further constraints on message flow. For any user
   message that arrives buffer room is guaranteed. All control messages
   can be processed without requiring additional storage to be
   allocated. Attempts by a user process to issue too many listens can
   be thwarted by local control procedures.

   Inefficiencies in storage will result when the number of outstanding
   connections gets large. One price of coding simplicity is a fifty
   percent utilization of buffer space. On large hosts it may prove
   advantageous to implement some of the following NCP extensions. With
   more complicated flow control procedures, it becomes possible for an
   NCP to allocate more buffer space than actually exists and still not
   to get into trouble. Other extensions provide message compression,
   improved throughput and user transparent error recovery.

   Because some extensions require the cooperation of foreign hosts and
   assume that they have implemented more than the minimal NCP it is
   proposed that an inquiry control message be used to find out what
   extensions the foreign host has implemented. The response to an INQ
   will be a control message defining a host profile. If an "undefined
   error" message is returned, the foreign host is assumed to have only
   a minimal NCP.



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


   A simple extension is to define a control message that will replace
   user RFNM's. A user RFNM is a null text message sent, for example, as
   a reply when a file is transferred via a duplex link. They are
   inefficient since they tie up an entry in the IMP's link assignment
   table and degrade network throughput. A more efficient solution is to
   send a special message over the control link. In this way one short
   message can replace several user messages.

   URFNM <my socket> <your socket> <number of user RFNM's>

   Because the control link is concurrent with the return side of the
   user link, URFNM's can not be substituted for user RFNM's when there
   are other messages to be sent on the return link. Otherwise ordering
   will be lost and with it user transparency.

   Throughput can also be increased with a mechanism to add additional
   crates on a duplex link. This might be at user instigation or be a
   decision of the NCP.

   INC <my socket> <your socket> <number buffers desired>

   The foreign host replies to an increase request by returning an INCR.

   INCR <my socket> <your socket> <number buffers to be added>

   If the foreign NCP is unable to meet the additional buffer demand,
   <number buffers to be added> will be less than <number buffers
   desired> and possibly zero. The initial state of all local buffers
   added is "filled with empty crate" and of all foreign buffers
   "empty".

   The spare argument in the RFDL and ACDL could be used to declare the
   maximum sized message that will actually be sent in that direction. A
   perceptive NCP could observe this information and allocate smaller
   buffers. A lesser NCP could ignore it and always assume maximum
   length messages. For example, if the field were zero then only user
   RFNM's would be sent. A smart NCP would allocate no storage at all.

   If the NCP retains a copy of each user message sent over the network
   until a reply is returned, an automatic error recovery procedure can
   be implemented. Because the capacity of the link is always known, an
   NCP can determine whether there are messages in transit. This is done
   by first sending a STOP message to the foreign NCP:

   STOP <my socket> <your socket>

   The STOP message tells the foreign NCP to temporarily stop
   transmitting messages over the selected link. Unlike CEASE-ON-LINK



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


   there is no guarantee as to how many messages will be sent before the
   STOP takes effect. The local NCP then sends a link inquiry message:

   LINQ <my socket> <your socket>

   The reply gives the number of crates at the foreign end of the link.
   The LINQ message is repeated until this number plus the number of
   local crates equals the capacity of the link. At this time no
   messages are in transit and the two ends of the link have been
   synchronized. Messages can now be identified relative to the
   synchronization point. Thus the local NCP can send a control message
   asking, for example, that the third to last message be retransmitted.
   The foreign NCP is able to identify which message this is and to
   retransmit it. Once all errors have been recovered a START control
   message, similar in format to the STOP, is sent to the foreign NCP
   and normal operation continues. The entire recovery procedure can be
   transparent to both user processes.

   It is expected that the larger hosts will not adhere strictly to the
   worst case storage allocation requirements. Rather they will allocate
   more buffers than they have and reply on statistics to keep them out
   of trouble most of the time. Such conduct is perfectly permissible as
   long as it is transparent to foreign hosts. The protocol allows an
   NCP to lie about storage allocation as long as he is not caught. In
   situations where detection appears imminent some of the following
   control mechanisms will need to be applied. They are listed in
   increasing order of power.

   a) Do not send out any user RFNM's or other short messages. There is
   a good chance that they will be replaced by longer messages that will
   strain buffer capacity even more.

   b) Try not to accept any new messages from the IMP. Block local
   processes attempting to issue messages.

   c) Issue DEC's to free up buffer space. Do not allocate more than one
   buffer to RFDL's and refuse INC's.

   d) Fake errors in messages waiting for local user action. Do this
   only if the host that sent it has implemented error recovery. This
   will free buffer space and allow you to recover later. This final
   measure is admittedly a last resort, but it should be powerful enough
   to control any emergency.

   It is the hope of the author that the above protocol presents an
   attractive alternative to that proposed by RFC 54 and its additions.
   Although it appears at a late date, it should not be more than a
   minor jolt to implementation efforts. It is simple enough to be



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


   implemented quickly. If adopted, a majority of the present sites
   could be talking intelligently with one another by the end of the
   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 ]

































Kalin                                                           [Page 8]