rfc48.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,012 行 · 第 1/3 页

Network Working Group                                          J. Postel
Request for Comments: 48                                      S. Crocker
                                                                    UCLA
                                                          April 21, 1970


                      A Possible Protocol Plateau

I. Introduction

   We have been engaged in two activities since the network meeting of
   March 17, 1970 and, as promised, are reporting our results.

   First, we have considered the various modifications suggested from
   all quarters and have formed preferences about each of these.  In
   Section II we give our preferences on each issue, together with our
   reasoning.

   Second, we have tried to formalize the protocol and algorithms for
   the NCP, we attempted to do this with very little specification of a
   particular implementation.  Our attempts to date have been seriously
   incomplete but have led to a better understanding.  We include here,
   only a brief sketch of the structure of the NCP.  Section III gives
   our assumptions about the environment of the NCP and in Section IV
   the components of the NCP are described.

II. Issues and Preferences

   In this section we try to present each of the several questions which
   have been raised in recent NWG/RFC's and in private conversations,
   and for each issue, we suggest an answer or policy.  In many cases,
   good ideas are rejected because in our estimation they should be
   incorporated at a different level.

      A. Double Padding

         As BBN report #1822 explains, the Imp side of the Host-to-Imp
         interface concatenates a 1 followed by zero or more 0's to fill
         out a message to an Imp word boundary and yet preserve the
         message length.  Furthermore, the Host side of the Imp-to-Host
         interface extends a message with 0's to fill out the message to
         a Host word boundary.

         BBN's mechanism works fine if the sending Host wants to send an
         integral number of words, or if the sending Host's hardware is
         capable of sending partial words.  However, in the event that





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


         the sending Host wants to send an irregular length message and
         its hardware is only capable of sending word-multiple messages,
         some additional convention is needed.

         One of the simplest solutions is to modify the Imp side of the
         Host-to-Imp interface so that it appends only 0's.  This would
         mean that the Host software would have to supply the trailing
         1.  BBN rejected the change because of an understandably strong
         bias against hardware changes.  It was also suggested that a
         five instruction patch to the Imp program would remove the
         interface supplied 1, but this was also rejected on the new
         grounds that it seemed more secure to depend only upon the Host
         hardware to signal message end, and not to depend upon the Host
         software at all.

         Two other solutions are also available.  One is to have "double
         padding", whereby the sending Host supplies 10* and the network
         also supplies 10*.  Upon input, a receiving Host then strips
         the trailing 10* 10*.  The other solution is to make use of the
         marking.  Marking is a string of the form 0*1 inserted between
         the leader and the text of a message.  The original intent of
         marking was to extend the leader so that the sending Host could
         _begin_ its text on a word boundary.  It is also possible to
         use the marking to expand a message so that it _ends_ on a word
         boundary.

         Notice that double padding could replace marking altogether by
         abutting the text beginning against the leader.  For 32 bit
         machines, this is convenient and marking is not, while for
         other lengths, particularly 36 bit machines, marking is much
         more convenient than double padding.

         We have no strong preference, partially because we can send
         word fragments.  Shoshani, et al in NWG/RFC #44 claim that
         adjusting the marking does not cause them any problems, and
         they have a 32 bit machine.  Since the idea of marking has been
         accepted for some time, we suggest that double padding not be
         used and that marking be used to adjust the length of a
         message.  We note that if BBN ever does remove the 1 from the
         hardware padding, only minimal change to Host software is
         needed on the send side.

         A much prettier (and more expensive) arrangement was suggested
         by W. Sutherland.  He suggested that the Host/Imp interfaces be
         smart enough to strip padding or marking and might even parse
         the message upon input.





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


      B. Reconnection

         A very large population of networkers has beat upon us for
         including dynamic reconnection in the protocol.  We felt it
         might be of interest to relate how it came to be included.

         After considering connections and their uses for a while, we
         wondered how the mechanism of connections compared to existing
         forms of intra-Host interprocess communication.  Two aspects
         are of interest, what formalisms have been presented in the
         literature, and what mechanisms are in use.  The formalisms are
         interesting because they lead to uniform implementations and
         parsimonious design.  The existing mechanisms are interesting
         because they point out which problems need solving and
         sometimes indicate what an appropriate formalism might be.  In
         particular, we have noticed that the mechanisms for connecting
         a console to the logger upon dial in, the mechanisms for
         creating a job, and the mechanisms for passing a console around
         to various processes within a job tend to be highly
         idiosyncratic and distinct from all other structures and
         mechanisms within an operating system.

         With respect to the literature, it appears there is only one
         idea with several variations, viz processes should share a
         portion of their address spaces and cooperatively wake up each
         other.  Semaphores and event channels are handy extensions of
         wake up signals, but the intent is basically the same.  (Event
         channels could probably function as connections, but it seems
         not to be within their intended use.  In small systems, the
         efficiency and capacity of event channels are inversely
         related.)

         With respect to existing implementations, we note that several
         systems allow a process to appear to be a file to another
         process.  Some systems, e.g. the SDS-940 at SRI impose a
         master/slave relationship between two processes so connected,
         but other systems provide for a coequal relationship e.g. the
         AI group's PDP-6 system at MAC.  The PDP-6 system also has a
         feature whereby a superior process can "surround" an inferior
         process with a mapping from device and file names to other
         device and file names.  Consoles have nearly the same semantics
         as files, so it is quite reasonable for an inferior process to
         believe it is communicating with the console but in fact be
         communicating with another process.

         The similarity between network connections and existing
         sequential interprocess connections supports our belief that
         network connections are probably the correct structure for



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


         using the network.  Moreover, the structure is clean enough and
         compatible with enough machines to pass as a formalism or
         theory, at least to the extent of the other forms of
         interprocess communication presented in the literature.

         Any new formalism, we believe, must meet at least the following
         two tests:

            1. What outstanding problems does it solve?
            2. Is it closed under all operations?

         In the case of network connections, the candidates for the
         first are the ones given above, i.e. all operations involving
         connecting a console to a job or a process.  Also of interest
         are the modelling of sequential devices such as tape drives,
         printers and card readers, and the modeling of their buffering
         (spooling, symbiont) systems.

         The second question mentions closure.  In applying the
         connection formalism to the dial-in and login procedures, we
         felt the need to include some sort of switching or
         reconnection, and an extremely mild form is presented in an
         SJCC paper, which is also NWG/RFC #33.  This mild form permits
         only the substitution of AEN's, and even then only at the time
         of connection establishment. However, it is a common experience
         that if an operation has a natural definition on an extended
         domain, it eventually becomes necessary or at least desirable
         to extend its definition.  Therefore, we considered the
         following extensions:

            1. Switching to any other socket, possibly in another Host.
            2. Switching even after data flow has started.

         There is even some precedent for feeling these extensions might
         be useful.  In one view of an operating system, we see all
         available phone lines as belonging to a live process known as
         the logger.  The logger answers calls, screens users, and
         creates jobs and processes.  One of the features of most
         telephone answering equipment is that many phone lines may
         serve the same phone number by using a block of sequential
         numbers and a rotary answering system.  In our quest for
         accurate models of practical systems, we wanted to be able to
         provide equivalent service to network users, i.e. they should
         be able to call a single advertised number and get connected to
         the logger.  Thus a prima facie case for switching is
         established.





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


         Next we see that after the logger interrogates a prospective
         user, it must connect the user to a newly created job.  Data
         flow between the user and the logger has already commenced, so
         flow control has to be meshed with switching if it is desired
         not to lose or garble data in transit.

         With respect to inter-Host switching, we find it easy to
         imagine a utility service which is distributed throughout the
         network and which passes connections from one socket to another
         without the knowledge of the user.  Also, it is similar to the
         more sophisticated telephone systems, to standard facilities of
         telephone company operators, and to distributed private
         systems.

         These considerations led us to investigate the possibility of
         finding one type of reconnection which provided a basis for all
         known models.  The algorithm did not come easily, probably
         because of inexperience with finite state automata theory, but
         eventually we produced the algorithm presented in NWG/RFC #36.
         A short time later, Bill Crowther produced an equivalent
         algorithm which takes an alternate approach to race conditions.

         Networkers seem to have one of two reactions.  Either it was
         pretty and (perhaps ipso facto) useful, or it was complex and
         (again perhaps ipso facto) unnecessary.  The latter group was
         far more evident to us, and we were put into the defensive
         position of admitting that dynamic reconnection was only

            1. pretty
            2. useful for login and console passing

         In response to persistent criticism, we have made the following
         change in the protocol.  Instead of calling socket <O,H,O> to
         login, sockets of the form <U,H,O> and <U,H,1> are the input
         and output sockets respectively of a copy of the logger or, if
         a job has been stared with user id U, these sockets are the
         console sockets.  The protocol for login is thus to initiate a
         connection to <U,H,O> and <U,H,1>.  If user U is not in use, a
         copy of the logger will respond and interrogate the caller.  If
         user id U is in use, the call will be refused.  This
         modification was suggested by Barry Wessler recently.  (Others
         also suggested this change much earlier; but we rejected it
         then.)

         The logger may demand that the caller be from the same virtual
         net, i.e. the caller may have user id U in some other Host, or
         it may demand that the user supply a password matched to user




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


         id U, or it may demand both.  Some systems may even choose to
         permit anybody to login to any user id.

         After login, AEN's 0 and 1 remain the console AEN's.  Each
         system presumably has mechanisms for passing the console, and
         these would be extended to know about AEN's 0 and 1 for network
         users.  Passing the console is thus a matter of reconnecting
         sockets to ports, and happens within the Host and without the
         network.

         In conversations with Meyer and Skinner after NWG/RFC #46 was
         received, they suggested a login scheme different from both
         Meyer's and ours in section above.  Their new scheme seemed a
         little better and we look forward to their next note.

         It is generally agreed that login should be "third-level", that
         is, above the NCP level.  We are beginning to be indifferent
         about particular logins schemes; all seem ok and none impress
         us greatly.  We suggest that several be tried.  It is some
         burden, of course, to modify the local login procedure, but we
         believe it imposes no extra hardship to deal with diverse login
         procedures.  This is because the text sequences and interrupt
         conventions are so heterogenous that the additional burden of
         following, say, our scheme on our system and Meyer's on Multics
         is minimal.

         We are agreed that reconnection should not be required in the
         initial protocol, and we will offer it later as an optional and
         experimental tool.  In addition, we would like to be on record
         as predicting that general reconnection facilities will become
         useful and will provide a unifying framework for currently ad
         hoc operating system structures.

      C. Decoupling Connections and Links

         Bill Crowther (BBN) and Steve Wolfe (UCLA) independently have
         suggested that links not be assigned to particular connections.
         Instead, they suggest, include the destination socket as part
         of the text of the message and then send messages over any
         unblocked link.

         We discussed this question a little in NWG/RFC #37, and feel
         there is yet an argument for either case.  With the current
         emphasis on simplicity, speed and small core requirements, it
         seems more efficient to leave links and connections coupled.
         We, therefore, recommend this.





Postel & Crocker                                                [Page 6]