RFC 60 (rfc60) - Page 2 of 8
Simplified NCP Protocol
Alternative Format: Original Text Document
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