RFC 33
New Host-Host Protocol
Okay, Title Block First 🎀
RFC 33 is titled New HOST-HOST Protocol and sits in the Network Working Group. It was written by S. Crocker (UCLA), S. Carr (University of Utah), and V. Cerf (UCLA), and it's dated 12 February 1970. The header doesn't list a category or status, and it doesn't say it obsoletes or updates anything. It does mention that the protocol has changed a lot from the old one in NWG/RFC 11 🌸
A Quick Note From the Authors 💌
Attached is a copy of the paper to be presented at the SJCC on the HOST-HOST Protocol. It shows many changes from the old protocol in NWG/RFC 11, and those changes came out of the network meeting on December 8, 1969. The attached document doesn't have enough info to write an NCP yet, so I'll send out another memo or so soon 💅 Responses are welcome, either as NWG/RFC's or as 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] Literally the big leagues 💖 The types of machines and operating systems involved 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 members 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 that 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 only been 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). 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 those 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 🙈👑
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 everyone involved. 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 the 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] Okay the IMP is basically the bouncer at the door of every site 💅
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. Lowkey not our problem today 💀
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. Note the 256 vs 356 mismatch in the original, I'm keeping both as written 🙈
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. Part 1 of 5, the good stuff is coming 🌈💖
DESIGN CONCEPTS 💖
okay so the computers on this network have two big things in common. 🖥️ First, each one can do its own research without the network. Second, each one runs under a time-sharing system. Those two facts shaped the design philosophy below. 🧠✨
- First, keep local control. 🔐 The computers have their own purposes, so each one needs to stay in charge of its own administration. Every time-sharing supervisor already has detailed accounting and resource allocation, so the network load gets handled by those same mechanisms, the same way they handle locally generated load. Totally iconic. 👑
- Second, make interaction easy. 💬 Since every computer runs time-sharing, it made sense to support basic interactive mechanisms.
- Third, no restrictions. 🌈 The network is used by experienced programmers, so they need the widest freedom possible. Limits on character sets, programming languages, and so on would not be tolerated, so we just didn't add any. Periodt. 💅
- Fourth, keep the design open-ended. 🦋 Experienced programmers also need room to work, so the design stays open. We expect conventions to show up over time as people learn things, but we didn't want to force any of them on anyone. Not me imposing rules. 🙈
- Fifth, keep the OS changes small. 🛠️ Joining the network should be comfortable, or in some cases even possible at all, so the software interface should need minimal surgery on the HOST operating system. 🧚
- Finally, we except the assumption above. 🎀 We said earlier that network use is made of prolonged conversations rather than one-shot requests. This is the one place we make an exception to that. 💜
These ideas led to connections, a Network Control Program, a control link, control commands, sockets, and virtual nets. Let's go through them. 🫶
A connection is basically an extension of a link. It joins two processes so that the output of one is the input of the other. Connections are simplex, which means you need two of them if two processes want to talk in both directions. ↔️
Processes inside a HOST talk to the network through a Network Control Program (NCP). In most HOSTs the NCP is part of the executive, so processes use system calls to reach it. The NCP's main jobs are to establish connections, break connections, switch connections, and control flow. It's the boss of the connection stuff. 👑
To do its job, an NCP in one HOST has to talk to an NCP in another HOST. For that, one particular link between each pair of HOSTs is designated as the control link. Anything received over the control link is always read by the NCP as a sequence of one or more control commands. For example, one kind of control command assigns a link and starts a connection, and another kind says a connection has been terminated. We give a partial sketch of the syntax and semantics of control commands in the next section. ✨
Now the big question: how do you refer to processes in a foreign HOST? 🤔 Each HOST has its own internal naming scheme, and those schemes are often incompatible with each other. It isn't practical to force everyone onto one common internal process naming scheme, so we made an intermediate name space instead. Each HOST gets its own portion of that name space, and it's up to each HOST to map its internal process identifiers into that name space. 🗺️
The elements of this name space are called sockets. A socket is one end of a connection, and a connection is fully specified by a pair of sockets. 🎀 A socket is written as 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 shown in Figure 3. 🖼️
Each HOST is assigned every socket in the name space whose field (b) equals that HOST's own identification number. So the HOST number basically tells you who owns the socket. 🏠
A socket is either a receive socket or a send socket. You can tell which one from the lower-order bit of the AEN: 0 means receive and 1 means send. 📥📤 The other seven bits of the AEN just give each HOST a big population of sockets for every number in use. (AEN stands for "another eight-bit number," which is honestly the most honest acronym ever. 😭)
Each user gets a 24-bit user number that uniquely identifies them across the whole network. Usually this is the 8-bit HOST number of their home HOST, followed by 16 bits that uniquely identify them at that HOST. 🪪 But a user can also have a user number that isn't tied to any particular HOST. This is useful for mobile users who might not have a home HOST at all, or who have more than one. ✈️
Here's how the 24-bit user number gets used. When a user signs onto a HOST, that user number gets looked up. After that, every process the user creates is tagged with the user number. When a user signs onto a foreign HOST through the network, the same user number tags the processes they create there too. The foreign HOST figures out the user number either by checking a table at login time, the same way the home HOST does, or by noticing the identification of the caller. 🔍 Because the number follows the user around, each user ends up with their own virtual net made of the processes they created. That virtual net can stretch across any number of HOSTs. 🕸️ This makes it easy for a user to hook up their processes in whatever arrangement they want, and they can still connect those processes with processes in other virtual nets. Main character energy. 🌟
Now we can describe how sockets relate to processes (see Figure 4). For each user number at each HOST there are 128 send sockets and 128 receive sockets. 📊 A process can ask its local NCP for any one of the sockets that share its user number, and the request is granted as long as that socket isn't already in use. The key thing to get here is that a socket a process asks for can only already be in use by another process in the same virtual net. And a process like that is controlled by the same user, so it's all one person's stuff. 💜
Here's the unusual part of the HOST-HOST protocol: a process is allowed to switch its end of a connection from one socket to another. ✨ The new socket can be in any virtual net and at any HOST, and the process can start a switch either while the connection is being set up or later on. Full switching is pretty complex to implement and isn't really relevant to the rest of this paper, so we'll only explain a limited form. In the limited form, a process can swap in one socket for another while it's establishing a connection. The new socket has to have the same user number and HOST number, and the connection still goes to the same process. 🎀 This kind of switching is really just a way of relabelling a socket, since nothing changes in how messages are routed. Free and easy. 🦋
In the next section we document the system calls and control commands. In the section after that, we think about how login might be implemented. 🧚
SYSTEM CALLS AND CONTROL COMMANDS 📞
Here we sketch how to set up, switch, and break a connection. Like we said above, the NCP talks to user processes through system calls and talks to other NCPs through control commands. So we'll start with a partial description of both. 💬
Just a heads up: system calls will be different on every operating system, so treat the following as a rough guide, not gospel. 🙈 We assume a process has several input-output paths, which we'll call ports. Each port can be connected to a sequential I/O device, and while it's connected, it only moves information in one direction. We also assume the process gets blocked (dismissed, slept) while a transmission is going on. Here's the list of system calls: 📋
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 start the connection. The second one is used while the connection exists. 🚀
<foreign socket> is the 40-bit socket name of the far end of the connection. 🌍
The lower-order bits of <AEN 1> and <AEN 2> have to match each other, and both have to be the complement of the lower-order bit of <foreign socket>. ⚠️
The NCP glues <AEN 1> and <AEN 2> each to the user number of the process and the HOST number, which makes two 40-bit sockets. Then it sends a Request for Connection (RFC) control command to the distant NCP. If the distant NCP says yes, the connection is established and the process gets unblocked. ✅ If the distant NCP says no, the local NCP unblocks the requesting process but tells it the system call failed. 💀
Listen <port>, <AEN 1>Here <port> and <AEN 1> mean the same thing as above. The NCP holds on to the ports and <AEN 1> and blocks the process. When an RFC control command shows up naming the local socket, the process gets unblocked and told that a foreign process is calling. 📞✨
Accept <AEN 2>Once a Listen has been satisfied, the process can either refuse the call or accept it and move it to another socket. To accept, the process issues the Accept system call, and then the NCP sends back an RFC control command. 🫶
Close <port>After a connection is set up, a process issues a Close to break it. A Close is also what you issue after a Listen if you want to refuse a call. 🙅♀️
Transmit <port>, <addr>If <port> is attached to a send socket, then <addr> points at a message to be sent. That message is preceded by its length in bits. 📤
If <port> is attached to a receive socket, a message gets stored at <addr>. The length of the message is stored first. 📥💖
Control Commands ✨
okay so the network talks in a little vocabulary of control commands 💅 Every command is an 8-bit operation code that says what it's for, followed by some parameters. The number and format of those parameters is fixed for each operation code, so no guessing 🎀 You can also pack a whole bunch of control commands bound for the same HOST into one single control message, which is so efficient it's giving 🧚
The big one is RFC, and it looks like this:
RFC <my socket 1>, <my socket 2>.
<your socket>, (<link>)A process sends this after it has executed either an Init system call or an Accept system call 🦋 A link is picked by the prospective receiver, so the link is left out whenever <my socket 1> is a send socket.
Now the Init and Accept thing is iconic and I need you to appreciate it 👑 Using the same command to start a connection (Init) and to answer one (Accept) is a huge win. If the reply were a different command from the one that started things, two processes could call each other and both end up stuck waiting for the other to respond 💀 With this setup, that deadlock can't happen, and it's a more compact way to connect a whole set of processes. Main character energy.
To tear things down, there's CLS:
CLS <my socket>, <your socket>Which terminates the specified connection 🌸
Then there's flow control, which is lowkey the most relatable part 🙈 When the receiving process isn't consuming its input as fast as it arrives, the receiving HOST uses its buffer space to queue up the waiting messages. Buffer space is limited, though, so the receiving HOST may need to stop the sending HOST from sending any more messages over that connection. It does that with CEASE:
CEASE <link>When the sending HOST gets this command, it may block the process that's generating the messages 😭
And when things calm down, the receiving HOST sends RESUME. It also goes from the receiving HOST to the sending HOST, and it negates a previous CEASE 🫶
RESUME <link>LOGGING IN 🔐
We assume that every HOST always has a process running that listens for login requests 👀 We call this process the logger, and it lives in a special virtual net whose user number is zero. The logger listens for calls on socket number 0. When a call comes in, the logger switches it over to a higher (even) numbered socket, and then returns a call to the socket numbered one less than the send socket that originally called. This is how the logger can initiate 127 conversations. Genius, honestly 🧠✨
Let's walk through an example. Say a user whose identification is X'010005' (user number 5 at UCLA) signs into UCLA, starts up one of his programs, and that program wants to start a process at SRI 🌈 No process except the logger is currently willing to listen to our user, so he runs:
Init, <port> = 1, <AEN 1> = 7, <AEN 2> = 7,
<foreign socket> = 0His process gets 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 gets notified when that message arrives, because it already ran:
Listen <port> = 9, <AEN 1> = 0.Then the logger runs:
Accept <AEN 2> = 88.In response to that Accept, the SRI NCP sends:
RFC <my socket 1> = X'0000000200'
<my socket 2> = X'0000000258'
<your socket> = X'0100050107'
<link> = 37The link got chosen from the set of available links 🦋 Next, the SRI logger runs:
Init <port> = 10
<AEN 1> = 89, <AEN 2> = 89,
<foreign socket> = X'0100050106'which makes the NCP send:
RFC <my socket 1> = X'0000000259'
<my socket 2> = X'0000000259'
<your socket> = X'0100050106'The process at UCLA is unblocked and told that its Init went through 🎉 Since the SRI logger always initiates a connection to the AEN one less than the one it has just been connected to, the UCLA process then runs:
Listen <port> = 11
<AEN 1> = 6and, once it's unblocked, runs:
Accept <AEN 2> = 6When all of these transactions are done, the UCLA process is doubly connected to the logger at SRI 💖 The logger then interrogates the UCLA process and, if it's satisfied, creates a new process at SRI. That new process gets tagged with user number X'010005', and both connections get switched over to it. Switching the connections to the new process is basically what "passing the console down" means in a lot of time-sharing systems 💜
USER LEVEL SOFTWARE 💅
At the user level, there are subroutines that manage data buffers and format input meant for other HOSTs 🍓 Users don't have to use them, though, since they have access to the network system calls in their monitor.
Beyond programming access, it's really desirable to have a subsystem program at each HOST that makes the network immediately accessible from a teletype-like device without any special programming ✨ Subsystems are commonly used system components like text editors, compilers and interpreters. An example of a network-related subsystem is TELNET, which lets users at the University of Utah connect to Stanford Research Institute and show up as regular terminal users. More sophisticated subsystems are expected to show up over time, but this basic one will make the early network useful right away 🙌
Picture this: a user at the University of Utah (UTAH) is sitting at a teletype dialed into the University's PDP-10/50 time-sharing system. They want 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 shown in Figure 5, and here's what each line of it means:
- (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 makes the appropriate system calls to establish a pair of connections to the SRI logger. The connections only get established if SRI accepts another foreign user.
The UTAH user is now in the pre-logged-in state at SRI 🧚 This is like 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-character transmission, since SRI's 940 requires it. Full duplex operation is allowed for by the PDP-10, though most Digital Equipment Corporations subsystems don't use it.
- (vi) and (vii) The 940 subsystem, CAL, is started.
At this point, the user wants to load a local CAL file into the 940 CAL subsystem, from the file system on their 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 their PDP-10 TELNET program, which sends the desired file to SRI from Utah over the connection that was just established for this purpose. The user's next statement is in CAL again 🦋
The TELNET subsystem coding should be minimal, because it's basically a shell program built over the network system calls 🫶 It effectively sets up 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, remote users can profitably use the network today 🌸
HIGHER LEVEL PROTOCOL 💅
okay so the network has a big problem 😭 when a user needs to interact a lot with a particular subsystem on a foreign HOST, things get messy fast. you've got heterogeneous consoles, local operating system overhead, and network transmission delays all fighting each other. without special strategies, a distant user might not be able to use the fancier subsystems at all 💀 graphics is the worst, but even plain teletype interaction can get rough.
picture this: a foreign subsystem was built for teletype consoles hooked up by telephone, and now it's open to network users. it might act like this 🎀
- Except for echoing and correction of mistyping, no action is taken until a carriage return is typed.
- All characters except "^", and "<-" and carriage returns are echoed as the character is typed.
- <- causes deletion of the immediately preceding character, and is echoed as that character.
- ^ causes all previously typed characters to be ignored. A carriage return and line feed are echoed.
- A carriage return is echoed as a carriage return followed by a line feed.
if every single character gets sent in its own message, then typing H E L L O <- <- P c.r. causes nine messages in each direction 😩 and it's even worse because each character gets handled by a user level program in the local HOST before it goes to the foreign HOST. not it 🙅♀️
now, if this example actually mattered, we'd quickly code rules 1 to 5 into a local HOST program and only send complete lines to the foreign HOST ✨ and if the foreign HOST program couldn't be changed to stop generating echoes, the local program could echo properly and throw away the later echoes from the foreign side. iconic problem-solving 👑 BUT the real issue is that we expect loads of these interaction schemes to show up, not just this one. we haven't found any general solutions yet, but a few observations and conjectures might point the way 🦋
on heterogeneous consoles: consoles are rarely compatible, but lots of them are equivalent 🌸 it's probably fair to treat a model 37 teletype as the equivalent of an IBM 2741. similarly, most storage scopes will form one equivalence class, and most refresh display scopes will form another. there might even be a hierarchy, where members of one class can be used in place of those in another, but not the other way around. any scope could be a decent sub for a teletype, but hardly the reverse 💜 this makes us wonder whether a network-wide language for consoles is possible. it would treat different classes of consoles separately, with semantics that fit each class. then every site could write interface programs for its own consoles to make them look like network standard devices 🫶
another thing: a user judges an interactive system by comparing how fast it responds with what they expect. sometimes they've made a minor request, so they want an immediate response. other times they've made a big request and are happy to wait ⏳ some interactive subsystems feel amazing to use because tons of work went into tailoring responses to what users expect. on the network though, a local user level process sits between the local console and the foreign subsystem, so response times for minor requests will probably get worse 😭 but here's the thing: all that tailoring is often pretty independent of the part of the subsystem doing the heavy computing or I/O. in that case, you might be able to split a subsystem into two sections. one is a "front end" that formats output for the user, accepts their input, and handles computationally simple responses like echoes ✨ in the example above, the program that accumulates a line and generates echoes would be the front end of some subsystem. and the local HOSTs have serious computational power, but our current designs only use them as data concentrators 🙈 which is kind of ironic, because not only are they underused that way, they also hurt performance with the delays they add.
these arguments led us to think about a Network Interface Language (NIL) 🌈 it would be a network-wide language for writing the front end of interactive subsystems, with subprograms that talk to each other through network-like connections. the plan is to ship the source code for a subsystem's front end to the local HOST, where it gets compiled and run.
during preliminary discussions, we agreed NIL should have at least these semantic properties, which aren't commonly found in other languages:
- Concurrency. Messages arrive asynchronously on different connections, and user input isn't synchronized with subsystem output, so NIL has to include semantics that accurately model the possible concurrencies.
- Program Concatenation. It's super useful to be able to slot a program in between two other programs. To make that work, the interconnection of programs gets specified at run time and isn't implicit in the source code.
- Device substitutability. It's normal to define languages so one device can be swapped for another. Here the requirement is that any device can be modeled by a NIL program. For example, if a network standard display controller manipulates tree-structures based on messages sent to it, those structures need to be easy to implement in NIL 🧚
NIL isn't fully specified yet, and people have doubts about how useful it'll be 🥺 those doubts come down to our conjecture that an interactive system can be split into a transportable front end, which satisfies a user's expectations at low cost, and a more substantial stay-at-home section. if that conjecture is false, NIL won't be useful. if it's true, it seems worth chasing 💖 testing the conjecture and developing NIL further will take priority once the low level HOST-HOST protocol has stabilized.
HOST/IMP INTERFACING 🔥
the hardware and software interfaces between HOST and IMP are a real concern for the HOST organizations 😤 since a standard IMP has to connect to a huge variety of HOST computers, the hardware interface was made bit serial and full-duplex. each HOST organization builds its own half of this very simple interface.
the software interface is just as simple. it's messages passed back and forth between the IMP and HOST programs. there are special error and signal messages, plus messages carrying normal data. messages waiting in queues on either machine get sent whenever the machine they're sitting in decides, without caring what the other computer needs 🙃
the current software interface causes needless rebuffering of all messages in the HOST, on top of the buffering already happening in the IMP. the messages have no particular order except their arrival times at the IMP. the Network Control Program at one HOST (e.g., UTAH) needs waiting RFNM's before anything else. at another site (e.g., SRI), the NCP would benefit from receiving messages for the user who's going to run next ✨
what we need is coding that reflects the specific needs of the HOST on both sides of the interface, so each side can make smart decisions about what to send next over the channel. with the current software interface, once one direction commits to a particular message, the channel can be locked up for up to 80 milliseconds! 😱 that's close to one teletype character time, and it needlessly limits full-duplex, character by character interactions over the net. at the very least, the IMP/HOST protocol should be expended to let each side help the other schedule messages over the channels 💜
CONCLUSIONS 🎀
as of February 1970, the initial network of four sites is just starting to get used 🌸 the communications system of four IMPs and wide band telephone lines has been operational for two months. programmers at UCLA have signed in as users of the SRI 940. even better, one of the authors (S. Carr), who lives in Palo Alto, uses the Salt Lake PDP-10 every day by connecting to SRI first. so we have firsthand experience that remote interaction is possible and highly effective 🙌
work on the ARPA network has opened up 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 new, and we're curious whether it's useful even when the processes live inside the same computer 🧚♀️
REFERENCES 📚
- L. ROBERTS, "The ARPA network", Invitational Workshop on Networks of Computers Proceedings, National Security Agency 1968 p 115 ff
- 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
- 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 ✨
okay bestie, here's the whole figure lineup 🎀 the list first, then each diagram in all its glory 💅
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.Figure 1 is the starting network setup 🧚 It's giving SRI, UCSB, UCLA, and UTAH all hooked up through their IMPs 🌸
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 configurationFigure 2 is a typical message from a 24-bit machine 🦋 Look at all those bits being carefully packed in, slay 💖
|<------------ 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 machineFigure 3 is a typical socket 🍓 The user number gets the whole first chunk, and the rest is split up between the AEN and the HOST number, which is so organised 🫶
24 8 8
+----------------------+-----------+----------+
| User Number | | |
+----------------------+-----------+----------+
| |___AEN
|
|___HOST number
Figure 3 A typical socketFigure 4 shows how sockets and processes relate 🌈 Two processes talk over a connection, with a send socket and a receive socket doing the heavy lifting. Main character energy 👑
|<--- connection --->|
+---------+ +---------+
| | link | |
| process |--(|--------------|)--| process |
| | ^ ^ | |
+---------+ | | +---------+
| |
send socket receive socket
Figure 4 The relationship between sockets and processesFigure 5 is a typical TELNET dialog 🙈 The original says underlined characters are the ones typed by the user, but the underlines didn't survive the trip into plain text, so the dialog itself isn't reproduced here. Iykyk 💀
The Figure 5 dialog and its underlining can't be shown in this terminal rendering, so only its caption and key note are kept above.
And that's the archive note at the very end 📚 This RFC was put into machine readable form for entry into the online RFC archives by Lorrie Shiota in 08/00 🫶
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Lorrie Shiota 08/00]📦 where this page comes from
- ietf: rfc33 1970-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms