GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc33

Network Working Group S. Crocker Request for Comments: 33 UCLA

                                                               S. Carr
                                                    University of Utah
                                                               V. Cerf
                                                                  UCLA
                                                      12 February 1970
                       New HOST-HOST Protocol
 Attached is a copy of the paper to be presented at the SJCC on the
 HOST-HOST Protocol.  It indicates many changes from the old protocol
 in NWG/RFC 11; these changes resulted from the network meeting on
 December 8, 1969.  The attached document does not contain enough
 information to write a NCP, and I will send out another memo or so
 shortly.  Responses to this memo are solicited, either as NWG/RFC's
 or personal notes to me.
                   HOST-HOST Communication Protocol
                         in the ARPA Network*
 by C. Stephen Carr
 University of Utah
 Salt Lake City, Utah
 and
 by Stephen D. Crocker
 University of California
 Los Angeles, California
 and
 by Vinton G. Cerf
 University of California
 Los Angeles, California
  • This research was sponsored by the Advanced Research Projects

Agency, Department of Defense, under contracts AF30(602)-4277 and

 DAHC15-69-C-0825.

INTRODUCTION

 The Advanced Research Projects Agency (ARPA) Computer Network
 (hereafter referred to as the "ARPA network") is one of the most
 ambitious computer networks attempted to date.  [1]  The types of

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

 machines and operating systems involved in the network vary widely.
 For example, the computers at the first four sites are an XDS 940
 (Stanford Research Institute), an IBM 360/75 (University of
 California, Santa Barbara), an XDS SIGMA-7 (University of California,
 Los Angeles), and a DEC PDP-10 (University of Utah).  The only
 commonality among the network membership is the use of highly
 interactive time-sharing systems; but, of course, these are all
 different in external appearance and implementation.  Furthermore, no
 one node is in control of the network.  This has insured reliability
 but complicates the software.
 Of the networks which have reached the operational phase and been
 reported in the literature, none have involved the variety of
 computers and operating systems found in the ARPA network.  For
 example, the Carnegie-Mellon, Princeton, IBM network consists of
 360/67's with identical software. [2]  Load sharing among identical
 batch machines was commonplace at North American Rockwell Corporation
 in the early 1960's.  Therefore, the implementers of the present
 network have been only slightly influenced by earlier network
 attempts.
 However, early time-sharing studies at the University of California
 at Berkeley, MIT, Lincoln Laboratory, and System Development
 Corporation (all ARPAA sponsored) have had considerable influence on
 the design of the network.  In some sense, the ARPA network of time-
 shared computers is a natural extension of earlier time-sharing
 concepts.
 The network is seen as a set of data entry and exit points into which
 individual computers insert messages destined for another (or the
 same) computer, and from which such messages emerge.  The format of
 such messages and the operation of the network was specified by the
 network contractor (BB&N) and it became the responsibility of
 representatives of the various computer sites to impose such
 additional constraints and provide such protocol as necessary for
 users at one site to use resources at foreign sites.  This paper
 details the decisions that have been made and the considerations
 behind these decisions.
 Several people deserve acknowledgement in this effort.  J. Rulifson
 and W. Duvall of SRI participated in the early design effort of the
 protocol and in the discussions of NIL.  G. Deloche of Thompson-CSF
 participated in the design effort while he was at UCLA and provided
 considerable documentation.  J. Curry of Utah and P. Rovner of
 Lincoln Laboratory reviewed the early design and NIL.  W. Crowther of
 Bolt, Beranek and Newman, contributed the idea of a virtual net.  The
 BB&N staff provided substantial assistance and guidance while
 delivering the network.

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

 We have found that, in the process of connecting machines and
 operating systems together, a great deal of rapport has been
 established between personnel at the various network node sites.  The
 resulting mixture of ideas, discussions, disagreements, and
 resolutions has been highly refreshing and beneficial to all
 involved, and we regard the human interaction as a valuable by-
 product of the main effect.

THE NETWORK AS SEEN BY THE HOSTS

 Before going on to discuss operating system communication protocol,
 some definitions are needed.
    A HOST is a computer system which is a part of the network,
    An IMP (Interface Message Processor) is a Honeywell DDP-516
    computer which interfaces with up to four HOSTs at a particular
    site, and allows HOSTs access into the network.  The configuration
    of the initial four-HOST network is given in figure 1.  The IMPs
    from a store-and-forward communications network.  A companion
    paper in these proceedings covers the IMPs in some detail. [3]
 A message is a bit stream less than 8096 bits long which is given to
 an IMP by a HOST for transmission to another HOST.  The first 32 bits
 of the message are the leader.  The leader contains the following
 information:
    (a) HOST
    (b) Message Type
    (c) Flags
    (d) Link Number
 When a message is transmitted from a HOST to its IMP, the HOST field
 of the leader names the receiving HOST.  When the message arrives at
 the receiving HOST, the HOST field names the sending HOST.
 Only two message types are of concern in this paper.  Regular
 messages are generated by a HOST and sent to its IMP for transmission
 to a foreign HOST.  The other message type of interest is a RFNM
 (Request-for-Next-Message).  RFNM's are explained in conjunction with
 links.
 The flag field of the leader controls special cases not of concern
 here.

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

 The link number identifies over which of 256 logical paths (links)
 between the sending HOST and the receiving HOST the message will be
 sent.  Each link is unidirectional and is controlled by the network
 so that no more than one message at a time may be sent over it.  This
 control is implemented using RFNM messages.  After a sending HOST has
 sent a message to a receiving HOST over a particular link, the
 sending HOST is prohibited from sending another message over that
 same link until the sending HOST receives a RFMN.  The RFNM is
 generated by the IMP connected to the receiving HOST, and the RFNM is
 sent back to the sending HOST after the message has entered the
 receiving HOST.  It is important to remember that there are 356 links
 in each direction and that no relationship among these is imposed by
 the network.
 The purpose of the link and RFMN mechanism is to prohibit individual
 users from overloading an IMP or a HOST.  Implicit in this purpose is
 the assumption that a user does not use multiple links to achieve a
 wide band, and to a large extent the HOST-HOST protocol cooperates
 with this assumption.  An even more basic assumption, of course, is
 that the network's load comes from some users transmitting sequences
 of messages rather than many users transmitting single messages
 coincidently.
 In order to delimit the length of the message, and to make it easier
 for HOSTs of differing word lengths to communicate, the following
 formatting procedure is used.  When a HOST prepares a message for
 output, it creates a 32-bit leader.  Following the leader is a binary
 string, called marking, consisting of an arbitrary number of zeros,
 followed by one.  Marking makes is possible for the sending HOST to
 synchronize the beginning of the text message with its word
 boundaries.  When the last bit of a message has entered an IMP, the
 hardware interface between the IMP and HOST appends a one followed by
 enough zeros to make the message length a multiple of 16 bits.  These
 appended bits are called padding.  Except for the marking and
 padding, no limitations are placed on the text of a message.  Figure
 2 shows a typical message sent by a 24-bit machine.

DESIGN CONCEPTS

 The computers participating in the network are alike in two important
 respects: each supports research independent of the network, and each
 is under the discipline of a time-sharing system.  These facts
 contributed to the following design philosophy.
 First, because the computers in the network have independent purposes
 it is necessary to preserve decentralized administrative control of
 the various computers.  Since all of the time-sharing supervisors
 possess elaborate and definite accounting and resource allocation

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

 mechanisms, we arranged matters so that these mechanisms would
 control the load due to the network in the same way that they control
 locally generated load.
 Second, because the computers are all operated under time-sharing
 disciplines, it seemed desirable to facilitate basic interactive
 mechanisms.
 Third, because this network is used by experienced programmers it was
 imperative to provide the widest latitude in using the network.
 Restrictions concerning character sets, programming languages, etc.
 would not be tolerated and we avoided such restrictions.
 Fourth, again because the network is used by experienced programmers,
 it was felt necessary to leave the design open-ended.  We expect that
 conventions will arise from time to time as experience is gained, but
 we felt constrained not to impose them arbitrarily.
 Fifth, in order to make network participation comfortable, or in some
 cases, feasible, the software interface to the network should require
 minimal surgery on the HOST operating system.
 Finally, we except the assumption stated above that network use
 consists of prolonged conversations instead of one-shot requests.
 These considerations led to the notions of connections, a Network
 Control Program, a control link, control commands, sockets, and
 virtual nets.
 A connection is an extension of a link.  A connection connects two
 processes so that output from one process is input to the other.
 Connections are simplex, so two connections are needed if two
 processes are to converse in both directions.
 Processes within a HOST communicate with the network through a
 Network Control Program (NCP).  In most HOSTs, the NCP will be a part
 of the executive, so that processes will use system calls to
 communicate with it.  The primary function of the NCP is to establish
 connections, break connections, switch connections, and control flow.
 In order to accomplish its tasks, a NCP in one HOST must communicate
 with a NCP in another HOST.  To this end, a particular link between
 each pair of HOSTs has been designated as the control link.  Messages
 received over the control link are always interpreted by the NCP as a
 sequence of one or more control commands.  As an example, one of the
 kinds of control commands is used to assign a link and initiate a

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

 connection, while another kind carries notification that a connection
 has been terminated.  A partial sketch of the syntax and semantics of
 control commands is given in the next section.
 A major issue is how to refer to processes in a foreign HOST.  Each
 HOST has some internal naming scheme, but these various schemes often
 are incompatible.  Since it is not practical to impose a common
 internal process naming scheme, an intermediate name space was
 created with a separate portion of the name space given to each HOST.
 It is left to each HOST to map internal process identifiers into its
 name space.
 The elements of the name space are called sockets.  A socket forms
 one end of a connection, and a connection is fully specified by a
 pair of sockets.  A socket is specified by the concatenation of three
 numbers:
    (a) a user number (24 bits)
    (b) a HOST number (8 bits)
    (c) AEN (8 bits)
 A typical socket is illustrated in Figure 3.
 Each HOST is assigned all sockets in the name space which have field
 (b) equal to the HOST's own identification.
 A socket is either a receive socket or a send socket, and is so
 marked by the lower-order bit of the AEN (0 = receive, 1 = send).
 The other seven bits of the AEN simply provide a sizable population
 of sockets for each used number at each HOST.  (AEN stands for
 "another eight-bit number")
 Each user is assigned a 24-bit user number which uniquely identifies
 him throughout the network.  Generally this will be the 8-bit HOST
 number of his home HOST, followed by 16 bits which uniquely identify
 him at that HOST.  Provision can also be made for a user to have a
 user number not keyed to a particular HOST, an arrangement desirable
 for mobile users who might have no home HOST or more than one home
 HOST.  This 24-bit user number is then used in the following manner.
 When a user signs onto a HOST, his user number is looked up.
 Thereafter, each process the user creates is tagged with his user
 number.  When the user signs onto a foreign HOST via the network, his
 same user number is used to tag processes he creates in that HOST.
 The foreign HOST obtains the user number either by consulting a table
 at login time, as the home HOST does, or by noticing the
 identification of the caller.  The effect of propagating the user's
 number is that each user creates his own virtual net consisting of
 processes he has created.  This virtual net may span an arbitrary

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

 number of HOSTs.  It will thus be easy for a user to connect his
 processes in arbitrary ways, while still permitting him to connect
 his processes with those in other virtual nets.
 The relationship between sockets and processes is now describable
 (see Figure 4).  For each user number at each HOST, there are 128
 send sockets and 128 receive sockets.  A process may request from the
 local NCP the use of any one of the sockets with the same user
 number; the request is granted if the socket is not otherwise in use.
 The key observation here is that a socket requested by a process
 cannot already be in use unless it is by some other process within
 the same virtual net, and such a process is controlled by the same
 user.
 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
 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc33.txt · Last modified: 2006/04/21 18:27 (external edit)