diff options
Diffstat (limited to 'doc/rfc/rfc33.txt')
| -rw-r--r-- | doc/rfc/rfc33.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc33.txt b/doc/rfc/rfc33.txt new file mode 100644 index 0000000..0192e0b --- /dev/null +++ b/doc/rfc/rfc33.txt @@ -0,0 +1,1067 @@ + + + + + + +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] + |