rfc55.txt

RFC 的详细文档！

Network Working Group                                          J. Newkirk
Request for Comments: 55                                        M. Kraley
                                                                  Harvard
                                                                J. Postel
                                                               S. Crocker
                                                                     UCLA
                                                             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....)

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








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


   CONNECT (P, AEN, FS, CR)

         P        specifies a port of the process
         AEN      specifies a local socket; the user number and host are
                  implicit
         FS       specifies a socket with any user number in any hose,
                  and with any AEN
         CR       the condition code returned

      CONNECT attempts to attach the local socket specified by AEN to
      the port P and to initiate a connection with a specific foreign
      socket, FS.  Possible values of CR are:

         CR=OK          The CONNECT was legal and the socket FS is being
                        contacted.  When the connection is established
                        or refused the status will be updated.

         CR = BUSY      The local socket is in use (illegal command
                        sequence).

         CR = BADSKT    The socket specification was illegal.

         CR = NOROOM    Local host's resources are exhausted.

         CR = HOMOSEX   Incorrect send/receive pair

         CR = IMP DEAD  Our imp has died

         CR = LINK DEAD The link to the foreign host is dead because:
                        1. the foreign Imp is dead,
                        2. the foreign host is dead, or
                        3. the foreign NCP does not respond.

   LISTEN (P, AEN, CR)

         P             specifies a port of the process
         AEN           specifies a local socket
         CR            the condition code returned

      The local socket specified by AEN is attached to port P.  If there
      is a pending call, it is processed; otherwise, no action is taken.
      When a call comes in, the user will be notified.  After examining
      the call, he may either accept or refuse it.  Possible values of
      CR are:

         CR = OK         Connection begun, listening

         CR = BUSY



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


         CR = NOROOM

         CR = IMP DEAD

         CR = LINK DEAD

   ACCEPT (P, CR)

         P       specifies a port of the process
         CR      the condition code returned

      Accept implies that the user process has inspected the foreign
      socket to determine who is calling and will accept the call.
      (Note: an interesting alternative defines ACCEPT as the implicit
      default condition.  Thus any incoming RFC automatically satisfies
      a LISTEN.)  Possible values of CR are:

         CR = BADSKT

         CR = NOROOM

         CR = IMP DEAD

         CR = LINK DEAD

         CR = BADCOMM   Illegal command sequence. (E.g., Accept issued
                        before a LISTEN.

         CR = PREMCLS   Foreign user aborted connection after RFC was
                        locally received but before Accept was executed.

   TRANSMIT (P, BUFF, BITSRQST, BITSACC, CR)

         P        specifies a port of the process
         BUFF     specifies the text buffer for transmission
         BITSRQST specifies the length to be transmitted in bits
         BITSACC  returns the number of bits actually transmitted
         CR       the condition code returned

       Transmission takes place.   Possible values for CR are:

         CR = OK

         CR = IMP DEAD

         CR = LINK DEAD





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


         CR = NOT OPEN  Connection is not open (illegal command
                        sequence).

         CR = BAD BOUND BITSRQST out of bounds (e.g., for a receive
                        socket BUFF was shorter than BITSRQST
                        indicated).

   INT (P, CR)

         P       specifies the local socket of this process
         CR      the condition code returned

      The process on the other (foreign) side of this port is to be
      interrupted.  Possible values of CR are:

         CR = OK

         CR = BADSKT

         CR = BADCOMM

         CR = IMP DEAD

         CR = LINK DEAD

   STATUS (P, RTAB, CR)

         P       specifies a port of this process
         RTAB    the returned rendezvous table entry
         CR      the condition code returned

      The relevant fields of the rendezvous table entry associated with
      this port are returned in RTAB.  This is the mechanism a user
      process employs for monitoring the state of a connection.
      Possible values of CR are:

         CR = OK

         CR = BADSKT












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


   CLOSE (P, CR)

         P       specifies a port of this process
         CR      the condition code returned

      Activity on the connection attached to this port stops, the
      connection is broken and the port becomes free for other use.
      Possible values of CR are:

         CR = OK

         CR = BADSKT

         CR = BADCOMM

         CR = IMP DEAD

         CR = LINK DEAD



IV.  The NCP - Gross Structure

   We view the NCP as having five component programs, several
   associative tables, and some queues and buffers.

      The Component Programs (see Fig. 4.1)

      1. The Input Handler

         This is an interrupt-driven routine.  It initiates Imp-to-Host
         transmission into a resident buffer and wakes up the input
         interpreter when transmission is complete.

      2. The Output Handler

         This is an interrupt-driven output routine.  It initiates Host-