rfc48.txt

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


RFC 48                A Possible Protocol Plateau             April 1970


      D. Error Reporting

         As mentioned by J. Heafner and E. Harslem of RAND, it is
         important to treat errors which might occur.  A good philosophy
         is to guard against any input which destroys the consistency of
         the NCP's data base.

         The specific formulation of the error command given by Heafner
         and Harslem in NWG/RFC #40 and by Meyer in NWG/RFC #46 seems
         reasonable and we recommend its adoption.  Some comments are in
         order, however.

         A distinction should be made between resource errors and other
         types of errors.  Resource errors are just the detection of
         overload conditions.  Overload conditions are well-defined and
         valid, although perhaps undesirable.  Other types of errors
         reflect errant software or hardware.  We feel that resource
         errors should not be handled with error mechanisms, but with
         mechanisms specific to the problem.  Thus the <CLS> command may
         be issued when there is no more room to save waiting <RFC>'s.
         Flow control protocol is designed solely to handle buffering
         overload.

         With respect to true errors, we are not certain what the value
         of the <ERR> command is to the recipient.  Presumably his NCP
         is broken, and it may only aggravate the problem to bombard it
         with error commands.  We therefore, recommend that error
         generation be optional, that all errors be logged locally in a
         chronological file and that <ERR> commands received likewise be
         logged in a chronological file.  No corrective action is
         specified at this time.

         In the short time the network has been up at UCLA, we have
         become convinced that the network itself will generate very few
         errors.  We have watched the BBN staff debug and test the IMP
         program, and it seemed that most of the errors affected timing
         and throughput rather than validity.  Hence most errors will
         probably arise from broken Hosts and/or buggy NCP's.

      E. Status Testing and Reporting

         A valuable debugging aid is to be able to get information about
         what a foreign NCP thinks is happening.  A convenient way to do
         this is to permit NCP's to send status whenever they wish, but
         to always have them do it whenever they receive a request.






Postel & Crocker                                                [Page 7]

RFC 48                A Possible Protocol Plateau             April 1970


         Since we view this feature as primarily a debugging tool, we
         suggest that a distinct link, like 255, be used.  The intent is
         that processing of status requests and generating of status
         messages should use as little of the normal machinery as
         possible.  Thus we suggest that link 255 be used to send
         "request status" and "status is" commands.  The form follows
         the suggestion on page 2 of NWG/RFC #40.

         Meyer's <ECO> command is easily implemented and serves the more
         basic function of testing whether a foreign NCP is alive.  We
         suggest that the length of the <ECO> command be variable, as
         there seems to be no significance in this context to 48 bits.
         Also, the value of a (presumably) 8 bit binary switch is
         unclear, so we recommend a pair of commands:

                   <ECO>   <length>   <text>
         and
                   <ERP>   <length>   <text>
         where
                   <length> is 8 bits.

         Upon receipt of an <ECO> command the NCP would echo with the
         <ERP> command.

      F. Expansion and Experimentation

         As Meyer correctly points out in NWG/RFC #46, network protocol
         is a layered affair.  Three levels are apparent so far.

            1. IMP Network Protocol
            2. Network Control Program Protocol
            3. Special user level or Subsystem Level Protocol

         This last level should remain idiosyncratic to each Host (or
         even each user).  The first level is well-specified by BBN, and
         our focus here is on level 2.  We would like to keep level 2 as
         neutral and simple as possible, and in particular we agree that
         login protocol should be as much on level 3 as possible.

         Simplicity and foresight notwithstanding, there will arise
         occasions when the level 2 protocol should change or be
         experimented with.  In order to provide for experimentation and
         change, we recommend that only link numbers 2 through 31 be
         assigned to regular connections, with the remaining link
         numbers, 32 to 255, used experimentally.  We have already
         suggested that link 255 be used for status requests and
         replies, and this is in consonance with our view of the
         experimental aspects of that feature.



Postel & Crocker                                                [Page 8]

RFC 48                A Possible Protocol Plateau             April 1970


         We also recommend that control command prefixes from 255
         downward be used for experimentation.

         These two conventions are sufficient, we feel to permit
         convenient experimentation with new protocol among any subset
         of the sites. We thus do not favor inclusion of Ancona's
         suggestion in NWG/RFC #42 for a message data type code as the
         first eight bits of the text of a message.

      G. Multiplexing Ports to Sockets

         Wolfe in NWG/RFC #38 and Shoshani et al in NWG/RFC #44 suggest
         that it should be possible to attach more than one port to a
         socket.  While all of our diagrams and prototypical system
         calls have shown a one-to-one correspondence between sockets
         and ports, it is strictly a matter of local implementation.  We
         note that sockets form a network-wide name space whose sole
         purpose is to interface between the idiosyncratic structures
         peculiar to each operating system.  Our references to ports are
         intended to be suggestive only, and should be ignored if no
         internal structures corresponds to them.  Most systems do have
         such structures, however, so we shall continue to use them for
         illustration.

      H. Echoing, Interrupts and Code Conversion

         1. Interrupts

            We had been under the impression that all operating systems
            scanned for a reserved character from the keyboard to
            interpret it as an interrupt signal.  Tom Skinner and Ed
            Meyer of MIT inform us that model 37 TTY's and IBM 2741
            generate a "long space" of 200-500 milliseconds which is
            detected by the I/O channel hardware and passed to the
            operating system as an interrupt.  The "long space" is not a
            character -- it has no ASCII code and cannot be program
            generated.

            Well over a year ago, we considered the problem of
            simulating console interrupts and rejected the <INT> type
            command because it didn't correctly model any system we
            knew.  We now reverse our position and recommend the
            implementation of an INTERRUPT system call and an <INT>
            control command as suggested by Meyer in NWG/RFC #46.







Postel & Crocker                                                [Page 9]

RFC 48                A Possible Protocol Plateau             April 1970


            Two restrictions of the interrupt facility should be
            observed.  First, when communicating with systems which scan
            for interrupt characters, this feature should not be used.
            Second, non-console-like connections probably should not
            have interrupts. We recommend that systems follow their own
            conventions, and if an <INT> arrives for a connection on
            which it shouldn't the <INT> should be discarded and
            optionally returned as an error.

         2. Echoing and Code Conversion

            We believe that each site should continue its current
            echoing policy and that code conversion should be done by
            the using process.  Standardization in this area should
            await further development.

            Ancona's suggestion of a table-driven front-end transducer
            seems like the right thing, but we believe that such
            techniques are part of a larger discussion involving
            higher-level languages for the network.

      I. Broadcast Facilities

         Heafner and Harslem suggest in NWG/RFC #39 a broadcast
         facility, i.e. <TER> and <BDC>.  We do not fully understand the
         value of this facility and are thus disposed against it.  We
         suspect that we would understand its value better if we had
         more experience with OS/360.  It is probably true in general
         that sites running OS/360 or similar systems will find less
         relevance in our suggestions for network protocol than sites
         running time-sharing systems.  We would appreciate any cogent
         statement on the relationship between OS/360 and the concepts
         and assumptions underlying the network protocol.

      J. Instance Numbers

         Meyer in NWG/RFC #46 suggests extending a socket to include an
         _instance_ code which identifies the process attached to the
         socket.  We carefully arranged matters so that processes would
         be indistinguishable.  We did this with the belief that both as
         a formal and as a practical matter it is of concern only within
         a Host whether a computation is performed by one or many
         processes.  Thus we believe that all processes within a job
         should cooperate in allocating AEN's.  If an operating system
         has facilities for passing a console from process to process
         within a job, these facilities mesh nicely with the current
         network protocol, even within reconnection protocol; but
         instance numbers interfere with such a procedure.



Postel & Crocker                                               [Page 10]

RFC 48                A Possible Protocol Plateau             April 1970


         We suggest this matter be discussed fully because it relates to
         the basic philosophy of sockets and connections.  Presently we
         recommend 40 bit socket numbers without instance codes.

      K. AEN's

         Nobody, including us, is particularly happy with our name AEN
         for the low order 8 bits of the socket.  We rejected _socket_
         number_, and are similarly unhappy with Meyer's _socket_code_.
         The word socket should not be used as part of the field name,
         and we solicit suggestions.

III. Environment

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

   Processes

   We envision that each process is tagged with a _user_number_. There
   may be more than one process with the same user number, and 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 each process has an event channel over which it
   can receive very short messages (several bits).  We will use this
   mechanism to notify a process that some action external to the
   process has occurred.

   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, and a socket is local to a process if their user numbers match
   and they are in the same host.  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 by
   concurrent events outside the process.  Whenever the status of a port
   is changed, the process is sent an event over its event channel which
   specifies which port's status has changed.  The process may then look
   at a port's status.

   These assumptions are used descriptive material which follows.
   However, these assumptions are not imposed by the network protocol
   and the implementation suggested by section IV is in no way binding.




Postel & Crocker                                               [Page 11]

RFC 48                A Possible Protocol Plateau             April 1970


   We wish to make very clear that this material is offered only to
   provide clues as to what the implementation difficulties might be and
   not to impose any particular discipline.

   For example, we treat <RFC>'s which arrive for unattached local
   sockets as valid and queue them.  If desired, an NCP may reject them,
   as Meyer suggests, or it might hold them for awhile and reject them
   if they're not soon satisfied.  The offered protocol supports all
   these options.

   Another local option is the one mentioned before of attaching
   multiple ports to a socket.  We have shown one-one correspondence but
   this may be ignored.  Similarly, the system calls are merely
   suggestive.

   System Calls

   These are typical system calls which a user process might execute.
   We show these only for completeness; each site will undoubtedly
   implement whatever equivalent set is convenient.

        We use the notation

        Syscall ( arg , arg ...; val ... )
                     1     2        1
   where
        Syscall is the system call
        arg  etc. are the parameters supplied with the call, and
           1
        val etc. are any values returned by the system call.
           1

   Init (P,AEN,FS,Bsiz;C)

        P      Specifies a port of the process.
        AEN    Specifies a local socket.  The user number of this
               process and host number of this host are implicit.
        FS     Specifies a socket with any user number in any host,
               with any AEN.
        Bsiz   Specified the amount of storage in bits the user wants
               to devote to buffering messages.
        C      The condition code returned.

   Init attempts to attach the local socket specified by AEN to the port
   P and to initiate a connection with socket FS.  Possible returned
   values of C are





Postel & Crocker                                               [Page 12]

RFC 48                A Possible Protocol Plateau             April 1970