rfc33.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   An unusual aspect of the HOST-HOST protocol is that a process may
   switch its end of a connection from one socket to another.  The new
   socket may be in any virtual net and at any HOST, and the process may
   initiate a switch either at the time the connection is being
   established, or later.  The most general forms of switching entail
   quite complex implementation, and are not germane to the rest of this
   paper, so only a limited form will be explained.  This limited form
   of switching provides only that a process may substitute one socket
   for another while establishing a connection.  The new socket must
   have the same user number and HOST number, and the connection is
   still established to the same process.  This form of switching is
   thus only a way of relabelling a socket, for no charge in the routing
   of messages takes place.  In the next section we document the system
   calls and control commands; in the section after next, we consider
   how login might be implemented.

SYSTEM CALLS AND CONTROL COMMANDS

   Here we sketch the mechanisms of establishing, switching and breaking
   a connection.  As noted above, the NCP interacts with user processes
   via system calls and with other NCPs via control commands.  We
   therefore begin with a partial description of system calls and
   control commands.

   System calls will vary from one operating system to another, so the
   following description is only suggestive.  We assume here that a
   process has several input-output paths which we will call ports.
   Each port may be connected to a sequential I/O device, and while
   connected, transmits information in only one direction.  We further
   assume that the process is blocked (dismissed, slept) while
   transmission proceeds.  The following is the list of system calls:






Crocker, et. al.                                                [Page 7]

RFC 33                   New HOST-HOST Protocol         12 February 1970


            Init      <port>, <AEN 1>, <AEN 2>, <foreign socket>

      where <port> is part of the process issuing the Init
                     _
            <AEN 1>   |
      and             +- are 8-bit AEN's (see Figure 2)
            <AEN 2>   |
                     _|

            The first AEN is used to initiate the connection; the second
            is used while the connection exists.

            <foreign socket> is the 40-bit socket name of the distant
            end of the connection.

            The lower-order bits of <AEN 1> and <AEN 2> must agree, and
            these must be the complement of the lower-order bit of
            <foreign socket>.

            The NCP concatenates <AEN 1> and <AEN 2> each with the user
            number of the process and the HOST number to form 40-bit
            sockets.  It then sends a Request for Connection (RFC)
            control command to the distant NCP.  When the distant NCP
            responds positively, the connection is established and the
            process is unblocked.  If the distant NCP responds
            negatively, the local NCP unblocks the requesting process,
            but informs it that the system call has failed.

            Listen <port>, <AEN 1>

      where <port> and <AEN 1> are as above.  The NCP retains the ports
            and <AEN 1> and blocks the process.  When an RFC control
            command arrives naming the local socket, the process is
            unblocked and notified that a foreign process is calling.

            Accept <AEN 2>

            After a Listen has been satisfied, the process may either
            refuse the call or accept it and switch it to another
            socket.  To accept the call, the process issues the Accept
            system call.  The NCP then sends back an RFC control
            command.

            Close <port>

            After establishing a connection, a process issues a Close to
            break the connection.  The Close is also issued after a
            Listen to refuse a call.



Crocker, et. al.                                                [Page 8]

RFC 33                   New HOST-HOST Protocol         12 February 1970


            Transmit <port>, <addr>

            If <port> is attached to a send socket, <addr> points to a
            message to be sent.  This message is preceded by its length
            in bits.

            If <port> is attached to a receive socket, a message is
            stored at <addr>.  The length of the message is stored
            first.

Control Commands

   A vocabulary of control commands has been defined for communication
   between Network Control Programs.  Each control command consists of
   an 8-bit operation code to indicate its function, followed by some
   parameters.  The number and format of parameters is fixed for each
   operation code.  A sequence of control commands destined for a
   particular HOST can be packed into a single control message.

      RFC   <my socket 1>, <my socket 2>.

            <your socket>, (<link>)

   This command is sent because a process has executed either an Init
   system call or an Accept system call.  A link is assigned by the
   prospective receiver, so it is omitted if <my socket 1> is a send
   socket.

   There is distinct advantage in using the same commands both to
   initiate a connection (Init) and to accept a call (Accept).  If the
   responding command were different from the initiating command, then
   two processes could call each other and become blocked waiting for
   each other to respond.  With this scheme, no deadlock occurs and it
   provides a more compact way to connect a set of processes.

      CLS      <my socket>, <your socket>

   The specified connection is terminated

      CEASE    <link>

   When the receiving process does not consume its input as fast as it
   arrives, the buffer space in the receiving HOST is used to queue the
   waiting messages.  Since only limited space is generally available,
   the receiving HOST may need to inhibit the sending HOST from sending
   any more messages over the offending connection.  When the sending
   HOST receives this command, it may block the process generating the
   messages.



Crocker, et. al.                                                [Page 9]

RFC 33                   New HOST-HOST Protocol         12 February 1970


      RESUME   <link>

   This command is also sent from the receiving HOST to the sending HOST
   and negates a previous CEASE.

LOGGING IN

   We assume that within each HOST there is always a process in
   execution which listens to login requests.  We call this process the
   logger, and it is part of a special virtual net whose user number is
   zero.  The logger is programmed to listen to calls on socket number
   0.  Upon receiving a call, the logger switches it to a higher (even)
   numbered sockets, and returns a call to the socket numbered one less
   than the send socket originally calling.  In this fashion, the logger
   can initiate 127 conversations.

   To illustrate, assume a user whose identification is X'010005' (user
   number 5 at UCLA) signs into UCLA, starts up one of his programs, and
   this program wants to start a process at SRI.  No process except the
   logger is currently willing to listen to our user, so he executes

         Init, <port> = 1, <AEN 1> = 7, <AEN 2> = 7,

               <foreign socket> = 0

   His process is blocked, and the NCP at UCLA sends

         RFC   <my socket 1> = X'0100050107',

               <my socket 2> = X'0100050107',

               <your socket> = X'000000200'

   The logger at SRI is notified when this message is received, because
   it has previously executed

         Listen   <port> = 9, <AEN 1> = 0.

   The logger then executes

         Accept   <AEN 2> = 88.










Crocker, et. al.                                               [Page 10]

RFC 33                   New HOST-HOST Protocol         12 February 1970


   In response to the Accept, the SRI NCP sends

         RFC   <my socket 1> = X'0000000200'

               <my socket 2> = X'0000000258'

               <your socket> = X'0100050107'

               <link> = 37

   where the link has been chosen from the set of available links.  The
   SRI logger than executes

         Init     <port> = 10

               <AEN 1> = 89, <AEN 2> = 89,

               <foreign socket> = X'0100050106'

   which causes the NCP to send

         RFC   <my socket 1> = X'0000000259'

               <my socket 2> = x'0000000259'

               <your socket> = X'0100050106'

   The process at UCLA is unblocked and notified of the successful Init.
   Because SRI logger always initiates a connection to the AEN one less
   than it has just been connected to, the UCLA process then executes

         Listen   <port> = 11

               <AEN 1> = 6

   and when unblocked

         Accept   <AEN 2> = 6

   When these transactions are complete, the UCLA process is doubly
   connected to the logger at SRI.  The logger will then interrogate the
   UCLA process, and if satisfied, create a new process at SRI.  This
   new process will be tagged with user number X'010005', and both
   connections wil be switched to the new process.  In this case,
   switching the connections to the new process corresponds to "passing
   the console down" in many time-sharing systems.





Crocker, et. al.                                               [Page 11]

RFC 33                   New HOST-HOST Protocol         12 February 1970


USER LEVEL SOFTWARE

   At the user level, subroutines which manage data buffer and format
   input designed for other HOSTs are provided.  It is not mandatory
   that the user use such subroutines, since the user has access to the
   network system calls in his monitor.

   In addition to user programming access, it is desirable to have a
   subsystem program at each HOST which makes the network immediately
   accessible from a teletype-like device without special programming.
   Subsystems are commonly used system components such as text editors,
   compilers and interpreters.  An example of a network-related
   subsystem is TELNET, which will allow users at the University of Utah
   to connect to Stanford Research Institute and appear as regular
   terminal users.  It is expected that more sophisticated subsystems
   will be developed in time, but this basic one will render the early
   network immediately useful.

   A user at the University of Utah (UTAH) is sitting at a teletype
   dialed into the University's PDP-10/50 time-sharing system.  He
   wishes to operate the Conversational Algebraic Language (CAL)
   subsystem on the XDS-940 at Stanford Research Institute (SRI) in
   Menlo Park, California.  A typical TELNET dialog is illustrated in
   Figure 5.  The meaning of each line of dialogue is discussed here.

      (i)      The user signs in at UTAH

      (ii)     The PDP-10 run command starts up the TELNET subsystem at
               the user's HOST.

      (111)    The user identifies a break character which causes any
               message following the break to be interpreted locally
               rather than being sent on the foreign HOST.

      (iv)     The TELNET subsystem will make the appropriate system
               calls to establish a pair of connections to the SRI
               logger.  The connections will be established only if SRI
               accepts another foreign user.

   The UTAH user is now in the pre-logged-in state at SRI.  This is
   analogous to the standard teletype user's state after dialing into a
   computer and making a connection but before typing anything.

      (v)      The user signs in to SRI with a standard login command.
               Characters typed on the user's teletype are transmitted
               unaltered through the PDP-10 (user HOST) and on to the
               940 (serving HOST).  The PDP-10 TELNET will have
               automatically switched to full-duplex, character-by-



Crocker, et. al.                                               [Page 12]

RFC 33                   New HOST-HOST Protocol         12 February 1970


               character transmission, since this is required by SRI's
               940.  Full duplex operation is allowed for by the PDP-10,
               though not used by most Digital Equipment Corporations
               subsystems.

      (vi) and (vii) The 940 subsystem, CAL, is started.

   At this point, the user wishes to load a local CAL file into the 940
   CAL subsystem, from the file system on his local PDP-10.

      (viii)   CAL is instructed to establish a connection to UTAH in
               order to receive this file.  "NETWRK" is a predefined 940
               name similar in nature to "PAPER TYPE" or "TELETYPE".

      (ix)     Finally, the user types the break character (#) followed
               by a command to his PDP-10 TELNET program, which sends
               the desired file to SRI from Utah on the connection just
               established for this purpose.  The user's next statement
               is in CAL again.

   The TELNET subsystem coding should be minimal for it is essentially a
   shell program built over the network system calls.  It effectively
   established a shunt in the user HOST between the remote user and a
   distant serving HOST.

   Given the basic system primitives, the TELNET subsystem at the user
   HOST and a manual for the serving HOST, the network can be profitably
   employed by remote users today.

HIGHER LEVEL PROTOCOL

   The network poses special problems where a high degree of interaction
   is required between the user and a particular subsystem in a foreign
   HOST.  These problems arise due to heterogeneous consoles, local