rfc33.txt

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

   operating systems overhead, and network transmission delays.  Unless
   we use special strategies it may be difficult or even impossible for
   a distant user to make use of the more sophisticated subsystems
   offered.  While these difficulties are especially severe in the area
   of graphics, problems may arise even for teletype interaction.  For
   example, suppose that a foreign subsystem is designed for teletype
   consoles connected by telephone, and then this subsystem becomes
   available to network users.  This subsystem might have the following
   characteristics.

      1. Except for echoing and correction of mistyping, no action is
         taken until a carriage return is typed.





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


      2. All characters except "^", and "<-" and carriage returns are
         echoed as the character is typed.

      3. <- causes deletion of the immediately preceding character, and
         is echoed as that character.

      4. ^ causes all previously typed characters to be ignored.  A
         carriage return and line feed are echoed.

      5. A carriage return is echoed as a carriage return followed by a
         line feed.

   If each character typed is sent in its own message, then the
   characters

      H E L L O <- <- P c.r.

   cause nine messages in each direction.  Furthermore, each character
   is handled by a user level program in the local HOST before being
   sent to the foreign HOST.

   Now it is clear that if this particular example were important, we
   would quickly implement rules 1 to 5 in a local HOST program and send
   only complete lines to the foreign HOST.  If the foreign HOST program
   could not be modified so as to not generate echoes, then the local
   program could not only echo properly, it could also throw away the
   later echoes from the foreign HOST.  However, the problem is not any
   particular interaction scheme; the problem is that we expect many of
   these kinds of schemes to occur.  We have not found any general
   solutions to these problems, but some observations and conjectures
   may lead the way.

   With respect to heterogeneous consoles, we note that although
   consoles are rarely compatible, many are equivalent.  It is probably
   reasonable to treat a model 37 teletype as the equivalent of an IBM
   2741.  Similarly, most storage scopes will form an equivalence class,
   and most refresh display scopes will form another.  Furthermore, a
   hierarchy might emerge with members of one class usable in place of
   those in another, but not vice versa.  We can imagine that any scope
   might be an adequate substitute for a teletype, but hardly the
   reverse.  This observation leads us to wonder if a network-wide
   language for consoles might be possible.  Such a language would
   provide for distinct treatment of different classes of consoles, with
   semantics appropriate to each class.  Each site could then write
   interface programs for its consoles to make them look like network
   standard devices.





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


   Another observation is that a user evaluates an interactive system by
   comparing the speed of the system's responses with his own
   expectations.  Sometimes a user feels that he has made only a minor
   request, so the response should be immediate; at other times he feels
   he has made a substantial request, and is therefore willing to wait
   for the response.  Some interactive subsystems are especially
   pleasant to use because a great deal of work has gone into tailoring
   the responses to the user's expectations.  In the network, however, a
   local user level process intervenes between a local console and a
   foreign subsystem, and we may expect the response time for minor
   requests to degrade.  Now it may happen that all of this tailoring of
   the interaction is fairly independent of the portion of the subsystem
   which does the heavy computing or I/O.  In such a case, it may be
   possible to separate a subsystem into two sections.  One section
   would be a "front end" which formats output to the user, accepts his
   input, and controls computationally simple responses such as echoes.
   In the example above, the program to accumulate a line and generate
   echoes would be the front end of some subsystem.  We now take notice
   of the fact that the local HOSTs have substantial computational
   power, but our current designs make use of the local HOST only as a
   data concentrator.  This is somewhat ironic, for the local HOST is
   not only poorly utilized as a data concentrator, it also degrades
   performance because of the delays it introduces.

   These arguments have led us to consider the possibility of a Network
   Interface Language (NIL) which would be a network-wide language for
   writing the front end of interactive subsystems.  This language would
   have the feature that subprograms communicate through network-like
   connections.  The strategy is then to transport the source code for
   the front end of a subsystem to the local HOST, where it would be
   compiled and executed.

   During preliminary discussions we have agreed that NIL should have at
   least the following semantic properties not generally found in other
   languages.

      1. Concurrency.  Because messages arrive asynchronously on
         different connections, and because user input is not
         synchronized with subsystem output, NIL must include semantics
         to accurately model the possible concurrencies.

      2. Program Concatenation.  It is very useful to be able to insert
         a program in between two other programs.  To achieve this, the
         interconnection of programs would be specified at run time and
         would not be implicit in the source code.






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


      3. Device substitutability.  It is usual to define languages so
         that one device may be substituted for another.  The
         requirement here is that any device can be modeled by a NIL
         program.  For example, if a network standard display controller
         manipulates tree-structures according to messages sent to it
         then these structures must be easily implementable in NIL.

   NIL has not been fully specified, and reservations have been
   expressed about its usefulness.  These reservations hinge upon our
   conjecture that it is possible to divide an interactive system into a
   transportable front end which satisfies a user's expectations at low
   cost and a more substantial stay-at-home section.  If our conjecture
   is false, then NIL will not be useful; otherwise it seems worth
   pursuing.  Testing of this conjecture and further development of NIL
   will take priority after low level HOST-HOST protocol has stabilized.

HOST/IMP INTERFACING

   The hardware and software interfaces between HOST and IMP is an area
   of particular concern for the HOST organizations.  Considering the
   diversity of HOST computers to which a standard IMP must connect, the
   hardware interface was made bit serial and full-duplex.  Each HOST
   organization implements its half of this very simple interface.

   The software interface is equally simple and consists of messages
   passed back and forth between the IMP and HOST programs.  Special
   error and signal messages are defined as well as messages containing
   normal data.  Messages waiting in queues in either machine are sent
   at the pleasure of the machine in which they reside with no concern
   for the needs of the other computer.

   The effect of the present software interface is the needless
   rebuffering of all messages in the HOST in addition to the buffering
   in the IMP.  The messages have no particular order other than arrival
   times at the IMP.  The Network Control Program at one HOST (e.g.,
   UTAH) needs waiting RFNM's before all other messages.  At another
   site (e.g., SRI), the NCP could benefit by receiving messages for the
   user who is next to be run.

   What is needed is coding representing the specific needs of the HOST
   on both sides of the interface to make intelligent decisions about
   what to transmit next over the channel.  With the present software
   interface, the channel in one direction once committed to a
   particular message is then locked up for up to 80 milliseconds!  This
   approaches one teletype character time and needlessly limits full-
   duplex, character by character, interactions over the net.  At the
   very least, the IMP/HOST protocol should be expended to permit each
   side to assist the other in scheduling messages over the channels.



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


CONCLUSIONS

   At this time (February 1970) the initial network of four sites is
   just beginning to be utilized.  The communications system of four
   IMPs and wide band telephone lines have been operational for two
   months.  Programmers at UCLA have signed in as users of the SRI 940.
   More significantly, one of the authors (S. Carr) living in Palo Alto
   uses the Salt Lake PDP-10 on a daily basis by first connecting to
   SRI.  We thus have first hand experience that remote interaction is
   possible and is highly effective.

   Work on the ARPA network has generated new areas of interest.  NIL is
   one example, and interprocess communication is another.  Interprocess
   communication over the network is a subcase of general interprocess
   communication in a multiprogrammed environment.  The mechanism of
   connections seems to be new, and we wonder whether this mechanism is
   useful even when the processes are within the same computer.

REFERENCES

   1     L. ROBERTS
         "The ARPA network"
         Invitational Workshop on Networks of Computers Proceedings
         National Security Agency 1968 p 115 ff

   2.    R M RUTLEDGE et al
         "An interactive network of time-sharing computers"
         Proceedings of the 24th National Conference
         Association for Computing Machinery 1969 p 431 ff

   3.    F E HEART  R E KAHN  S M ORNSTEIN  W R CROWTHER
         D C WALDEN
         "The interface message processors for the ARPA network"
         These Proceedings

LIST OF FIGURES

   Figure 1  Initial network configuration

   Figure 2  A typical message from a 24-bit machine

   Figure 3  A typical socket

   Figure 4  The relationship between sockets and processes

   Figure 5  A typical TELNET dialog.

             Underlined characters are those types by the user.



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


                                 SRI
                                _____
                               /     \
                              |  XDS  |
                              |  940  |
                               \_____/
                                  |
                            +----------+
                            |    IMP   |
                            +----------+
                             /   |    \
                            /    |     \
                           /     |      \  +----+    _____
                          /      |       \ | I  |   /     \
       ______     +----+ /       |        \| M  |--|  DEC  |
      /      \    | I  |/        |         | P  |  | PDP-10|
     |   IBM  |---| M  |         |         +----+   \_____/
     | 360/75 |   | P  |\        |
      \______/    +----+ \       |                    UTAH
                          \      |
        UCSB               \     |
                          +----------+
                          |    IMP   |
                          +----------+
                              |
                           ___|___
                          /       \
                         |   XDS   |
                         |(sigma)-7|
                          \_______/

                            UCLA

   Figure 1 Initial network configuration

















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


   |<------------ 24bits ----------->|
   |                                 |
   +---------------------------------+
   |                                 |
   |        Leader (32 bits)         |
   |               __________________|
   |              | 100 ---    ----0 |<----16 bits of marking
   +--------------+------------------+
   |                                 |
   |                                 |
   |   Text of messages (96 bits)    |
   |                                 |
   +------------------------+--------+
   | 100-----          ----0|
   +-------^----------------+
           |
           |______16 bits of padding added
                  by the interface

   Figure 2  A typical message from a 24-bit machine



          24                    8          8
   +----------------------+-----------+----------+
   |  User Number         |           |          |
   +----------------------+-----------+----------+
                                |          |___AEN
                                |
                                |___HOST number
   Figure 3 A typical socket



              |<--- connection --->|
   +---------+                      +---------+
   |         |        link          |         |
   | process |--(|--------------|)--| process |
   |         |   ^              ^   |         |
   +---------+   |              |   +---------+
                 |              |
             send socket    receive socket

   Figure 4 The relationship between sockets and processes

         [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Lorrie Shiota 08/00]




Crocker, et. al.                                               [Page 19]