Prototypical implementation of the NCP
RFC 55

Document Type RFC - Unknown (June 1970; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 55 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          J. Newkirk
Request for Comments: 55                                        M. Kraley
                                                                J. Postel
                                                               S. Crocker
                                                             19 June 1970

                A Prototypical Implementation of the NCP

   While involved in attempting to specify the formal protocol, we also
   attempted to formulate a prototypical NCP in an Algol-like language.
   After some weeks of concentrated effort, the project was abandoned as
   we realized that the code was becoming unreadable.  We still,
   however, felt the need to demonstrate our conception of how an NCP
   might be implemented; we felt that this would help suggest solutions
   for problems that might arise in trying to mold the formal
   specifications into an existing system.  This document is that
   attempt to specify in a prose format what an NCP could look like.

   There are obvious limitations on a project of this nature.  We do
   not, and cannot, know all of the quirks of the various systems that
   must write an NCP.  We are forced to make some assumptions about the
   environment, system calls, and the like.  We have tried to be as
   general as possible, but no doubt many sites will have completely
   different ways of conceptualizing the NCP.  There is great difficulty
   involved in conveying our concepts and the mechanisms that deal with
   these concepts to people who have wholly different ways of looking at
   things.  We have, however, benefited greatly by trying to actually
   code this program for our fictitious machine.  Many unforeseen
   problems surfaced during the coding, and we hope that by issuing this
   document we can help to alleviate similar problems which may arise in
   individual cases.

   There is, of course, absolutely no requirement to implement anything
   which is contained in this document.  The only rigid rules which an
   NCP _must_ conform to are stated in NWG/RFC#54.  This description is
   intended only as an example, _not_ as a model.

   In the discussion which follows we first describe the environment to
   be assumed and postulate a set of system calls.  We discuss the
   overall architecture of the NCP and the tables that will be used to
   hold relevant information.  Narratives of network operations follow.
   A state diagram is then presented as a convenient method for
   conceptualizing the cause-effect sequencing of events.  The detailed
   processing of each type of network event (system calls or incoming
   network messages) is then discussed.

Newkirk, et al.                                                 [Page 1]
RFC 55             Prototypical Implementation of NCP          June 1970

II. Environment

   We assume that the host will have a time-sharing operating system in
   which the CPU is shared by processes.

   We envision that each process is tagged with a user number.  There
   may be more than one process with the same user number; if so, they
   should all be cooperating with respect to using the network.

   We envision that each process contains a set of ports which are
   unique to the process.  These ports are used for input to or output
   from the process, from or to files, devices, or other processes.

   We also envision that a process is not put to sleep (i.e., blocked or
   dismissed) when it attempts to LISTEN or CONNECT.  Instead it is
   informed when some action is complete.  Of course, a process may
   dismiss itself so that it wakes up only on some external event.

   To engage in network activity, a process attaches a local socket to
   one of its ports.  Sockets are identified by user number, host and
   AEN; a socket is local to a process if the user numbers of the two
   match and they are in the same host.  Thus, a process need only
   specify an AEN when it is referring to a local socket.

   Each port has a status which is modified by system calls and
   concurrent events outside the process (e.g., a 'close connection'
   command from a foreign host).  The process may look at a port's
   status as any time (via the STATUS system call).

   We assume a one-to-one correspondence between ports and sockets.

III. System Calls

   These are typical system calls which a user process might execute.

         We use the notation

                  SYSCALL (ARG1, ARG2....)

                  SYSCALL is the name of the system call
                  ARGk, etc. are the parameters of the system call.

Newkirk, et al.                                                 [Page 2]
RFC 55             Prototypical Implementation of NCP          June 1970

Show full document text