RFC 62
Systems for Interprocess Communication in a Resource Sharing Computer Network
RFC 62 🎀
okay bestie, let's talk about this one 💅 It's from the Network Working Group, written by D. C. Walden of BBN Inc., dated 3 August 1970. It's giving sequel, because it supercedes NWG/RFC #61 🦋 The header doesn't name a category or status, so I'm not inventing one 💀
A System for Interprocess Communication in a Resource Sharing Computer Network ✨
1. Introduction ✨
okay so if you're trying to figure out how computers in a network should talk to each other, you basically have two options 🌸 You can roll up your sleeves and actually build a computer network with other people, getting influenced and maybe influencing your colleagues back. Or you can come up with an ideal theory of how things should be done, one better than the network you're helping build, and then hand it to the designers of future networks to study 📚 The author spent the past two years doing the first one. This paper comes from recently doing the second. 🧚
Here's the definition the author leans on: "A resource sharing computer network is defined to be a set of autonomous, independent computer systems, interconnected so as to permit each computer system to utilize all of the resources of the other computer systems much as it would normally call a subroutine." Roberts and Wessler explain this definition, and why a network like this is worth wanting, in [9] 🔥
There are two ways resource sharing can happen. It can be ad hoc, between every pair of computer systems in the network, or it can follow a systematic network-wide standard. This paper develops one possible network-wide system for resource sharing 💜
Here's the core idea 👑 The author thinks resources are naturally tied to processes<1> and only reachable by talking to those processes. So the fundamental problem of resource sharing is really the problem of interprocess communication. The author also agrees with Carr, Crocker, and Cerf [2] that interprocess communication over a network is just a subcase of general interprocess communication in a multi-programmed environment. literally a main character idea 😭
The study has two parts 🎀 First, the author builds a set of operations for interprocess communication within a single time-sharing system. These operations skip a lot of the techniques time-sharing systems use today, like communication through shared memory, and instead rely on things that can easily be generalized to let remote processes talk to each other. The second part presents that generalization. The paper also discusses how the generalized system applies to the ARPA Computer Network [9] 🌈
A bunch of people influenced these ideas ✨ The biggest influences were: 1) an early sketch of a Host protocol for the ARPA Network by S. Crocker of UCLA and W. Crowther of Bolt Beranek and Newman Inc. (BBN); 2) Ackerman and Plummer's paper on the MIT PDP-1 time-sharing system [1]; and 3) discussions with W. Crowther and R. Kahn of BBN about Host protocol, flow control, and message routing for the ARPA Network. The author hopes there are some original ideas in here too 🫶 But the author alone is responsible for pulling all these ideas together into the system described in the paper, and therefore responsible for any inconsistencies or bugs in it 🙈
It really needs saying: this paper does not represent an official BBN position on Host protocol for the ARPA Computer Network ⚠️
2. A System for Interprocess Communication within a Time-Sharing System 🦋
This section describes a set of operations that enable interprocess communication within a time-sharing system. Following the notation of [10], the author calls this interprocess communication facility an IPC 💖 To make the IPC easier to follow, the section first describes a model of a time-sharing system, then uses that model to show how the interprocess communication operations get used 🧚
The model time-sharing system has two pieces: the monitor and the processes 👑 The monitor does a lot of the heavy lifting. It switches control from one process to another when a process has used "enough" time, handles hardware interrupts, manages core and the swapping medium, controls the passing of control from one process to another (i.e., protection mechanisms), creates processes, takes care of sleeping processes, and provides a set of machine extending operations to the processes (often called Supervisor or Monitor Calls) 💅
The processes do the normal user work (user processes), plus the functions usually thought of as supervisor functions in a time-sharing system (systems processes), which the monitor doesn't perform in this model. A typical system process is the disc handler or the file system 💾 System processes are probably allowed to run in supervisor mode, so they actually execute I/O instructions and do other privileged operations that user processes aren't allowed to do. In every other way, user and system processes are identical. For efficiency, it can help to think of system processes as being locked in core 🌸
Protection isn't the focus here, even though it comes up later in the study. For now, the author assumes all the processes are "good" processes that never make any mistakes 🙈 If the reader wants a protection structure to keep in mind while reading, the capability system developed in [1][3][7][8] should do the trick 🔐
An example, bestie 🧚 Imagine our model time-sharing system just booted up with a bunch of processes always running 💖. These permanent processes have some universally known, permanently assigned ports<2>. Two of them are the logger-process and the teletype-scanner-process. When the teletype-scanner-process first starts running, it puts itself to sleep waiting for an interrupt from the hardware teletype scanner 😴. The logger-process also puts itself to sleep, waiting for a message from the teletype-scanner-process over the well-known permanent SEND and RECEIVE ports 🎀.
The teletype-scanner-process keeps a table indexed by teletype number 📋. Each entry holds a pair of port numbers for sending characters from that teletype to a process, and a pair of port numbers for receiving characters for that teletype from a process. Now, if a character arrives (waking up the teletype-scanner-process) and the process doesn't have an entry for that teletype, it grabs a pair of unique numbers from the monitor (via UNIQUE). Then it sends a message with that pair to the logger-process, using the ports the logger-process is known to have a RECEIVE pending on 📨. The scanner-process also enters the pair of numbers in the teletype table, and sends the character and all future characters from this teletype to the port with the first number from the port with the second number 💌.
The scanner-process must also pass a second pair of unique numbers to the logger-process for it to use for teletype output, and do a RECEIVE using these port numbers 🔁. When the logger-process receives the message from the scanner-process, it starts up a copy of what SDS 940 TSS [6] users call the executive<3>. It passes the port numbers to this copy of the executive, so this executive-process can also do its inputs and outputs to the teletype using these ports 💻. If the logger-process wants to get a job number and password from the user, it can temporarily use the port numbers to talk to the user before passing them on to the executive 🔑. The scanner-process could always use the same port numbers for a particular teletype, as long as the numbers were passed on to only one copy of the executive at a time 💅.
It is important to distinguish between passing a port from one process to another and passing a port number from one process to another 🧐. In the example above, characters from a particular teletype are sent by the teletype-scanner-process either to the logger-process or to an executive-process. The SEND port always stays in the teletype-scanner-process, while the RECEIVE port moves from the logger-process to the executive-process. On the other hand, the SEND port number is passed between the logger-process and the executive-process, so the process doing the RECEIVE can do a RECEIVE from the correct SEND port 🎯.
It is crucial that, once a process transfers a port to some other process, the first process no longer use the port 🚨. We could add a mechanism that enforces this, and the protected object system of [9] is one such mechanism. Using this mechanism, a process executing a SEND would need a capability for the SEND port, and only one capability for this SEND port would exist in the system at any given time. A process executing a RECEIVE would be required to have a capability for the RECEIVE port, and only one capability for this RECEIVE port would exist at a given time. Without such a protection mechanism, a port implicitly moves from one process to another when the processes merely use the port at disjoint times, even if the port's number is never explicitly passed 🔒.
Of course, if the protected object system is available to us, there is really no need for two port numbers to be specified before a transmission can take place 👑. The fact that a process knows an existing RECEIVE port number could be considered prima facie evidence of that process' right to send to that port. The difference between RECEIVE and RECEIVE ANY ports then depends solely on the number of copies of a particular port number that have been passed out. A system based on this approach would clearly be preferable to the one described here, if it was possible to assume that all autonomous time-sharing systems in a network would adopt this protection mechanism. If this assumption cannot be made, it seems more practical to require both port numbers 🫶.
Note that in the interprocess communication system (IPC) being described here, when two processes wish to communicate, they set up the connection themselves, and they are free to do it in a mutually convenient manner 🤝. For instance, they can exchange port numbers, or one process can pick all the port numbers and instruct the other process which to use. However, in a particular implementation of a time-sharing system, the builders of the system might choose to restrict the processes' execution of SENDs and RECEIVEs. They might forbid arbitrary passing around of ports and port numbers, requiring instead that the monitor be called (or some other special program) to perform these functions 🚧.
Flow control is provided in this IPC by the simple method of never starting data transmission resulting from a SEND from one process until a RECEIVE is executed by the receiver 🌊. Of course, interprocess messages may also be sent back and forth, suggesting that a process stop sending or that space be allocated 💬.
Generally, well-known permanently assigned ports are used via RECEIVE ANY and SEND FROM ANY. The permanent ports will most often be used for starting processes, so little data will be sent via them 🚀. If a process is running (perhaps asleep) and has a RECEIVE ANY pending, then any process knowing the receive port number can talk to that process without going through loggers 🗣️. This is obviously essential within a local time-sharing system, and it seems very useful in a more general network if the ideal of resource sharing is to be reached 🌐. For instance, in a resource sharing network, the programs in the subroutine libraries at all sites might have RECEIVE ANYs always pending over permanently assigned ports with well-known port numbers. Thus, to use a particular network resource such as matrix manipulation hardware, a process running anywhere in the network can send a message to the matrix inversion subroutine containing the matrix to be inverted and the port numbers to be used for returning the results 🧮.
An additional example demonstrates the use of the FORTRAN compiler 🧑💻. We have already explained how a user sits down at their teletype and gets connected to an executive, so we go on from there. The user is typing in and out of the executive, which is doing SENDs and RECEIVEs. Eventually the user types RUN FORTRAN, and the executive asks the monitor to start up a copy of the FORTRAN compiler. It passes to FORTRAN, as start-up parameters, the port numbers the executive was using to talk to the teletype. (This, at least conceptually, means FORTRAN is passed a port at which to RECEIVE characters from the teletype, and a port from which to SEND characters to the teletype.) FORTRAN is, of course, expecting these parameters, and does SENDs and RECEIVEs via the indicated ports to find out from the user what input and output files the user wants to use. FORTRAN types INPUT FILE? to the user, who responds F001.
FORTRAN then sends a message to the file-system-process, which is asleep waiting for something to do. The message is sent via well-known ports and asks the file system to open F001 for input. The message also contains a pair of port numbers that the file-system-process can use to send its reply. The file system looks up F001, opens it for input, makes some entries in its open file tables, and sends back to FORTRAN a message containing the port numbers FORTRAN can use to read the file. The same procedure is followed for the output file. When the compilation is complete, FORTRAN returns the teletype port numbers (and the ports) back to the executive, which has been asleep waiting for a message from FORTRAN, and then FORTRAN halts itself. The file-system-process goes back to sleep when it has nothing else to do<4> 😌.
Again, the file-system process can keep a small collection of port numbers which it uses over and over, if it can get file system users to return the port numbers when they have finished with them 🔄. Of course, when this collection of port numbers has eventually dribbled away, the file system can get some new unique numbers from the monitor.
3. A System for Interprocess Communication Between Remote Processes ✨
The IPC described in the previous section easily generalizes to allow interprocess communication between processes at geographically different locations, as, for example, within a computer network 🌍.
Consider first a simple configuration of processes distributed around the points of a star. At each point of the star there is an autonomous operating system<5>. A rather large, smart computer system, called the Network Controller, exists at the center of the star. No processes can run in this center system. Rather, it should be thought of as an extension of the monitor of each of the operating systems in the network 🌟.
If the Network Controller is able to perform the operations SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY, and UNIQUE, and if all of the monitors in all of the time-sharing systems in the network do not perform these operations themselves but instead ask the Network Controller to perform them for them, then the problem of interprocess communication between remote processes is solved 🎉. No further changes are necessary, since the Network Controller can keep track of which RECEIVEs have been executed and which SENDs have been executed, and match them up just as the monitor did in the model time-sharing system. A networkwide port numbering scheme is also possible, with the Network Controller knowing where (i.e., at which site) a particular port is at a particular time 🗺️.
Next, consider a more complex network in which there is no common center point, making it necessary to distribute the functions performed by the Network Controller among the network nodes. In the rest of this section I will show that it is possible to efficiently and conveniently distribute the functions performed by the star Network Controller among the many network sites, and still enable general interprocess communication between remote processes 💫.
Some changes must be made to each of the four SEND/RECEIVE operations described above to adapt them for use in a distributed Network Controller. To RECEIVE is added a parameter specifying a site to which the RECEIVE is to be sent. To the SEND FROM ANY and SEND messages is added a site to send the SEND to, although this is normally the local site. Both RECEIVE and RECEIVE ANY have added the provision for obtaining the source site of any received message. Thus, when a RECEIVE is executed, the RECEIVE is sent to the site specified, possibly a remote site. Concurrently, a SEND is sent to the same site, normally the local site of the process executing the SEND. At this site, called the rendezvous site, the RECEIVE is matched with the proper SEND, and the message transmission is allowed to take place from the SEND site to the site from whence the RECEIVE came 🤝✨.
okay bestie so a RECEIVE ANY never leaves the site it was made at 💖 and that's literally why SEND FROM ANY has to exist ✨ you need to be able to send to a RECEIVE ANY port without your message getting stuck waiting for a RECEIVE at the sending site 😭 could you build it so the SEND/RECEIVE rendezvous happens at the RECEIVE site and skip SEND FROM ANY completely? yes 🫶 but ngl, in my judgment being able to block a normal SEND at the source site more than makes up for the extra complexity 💅
At each site there's a rendezvous table 🎀 it holds an entry for every unmatched SEND or RECEIVE that shows up at that site, plus an entry for every RECEIVE ANY given at that site. the second a SEND/RECEIVE pair matches, it gets cleared from the table 🦋 same as the similar table in the model time-sharing system, SEND and RECEIVE entries get timed out if they sit unmatched for too long, and the originator gets notified 😭 RECEIVE ANY entries are cleared when a fulfilling message arrives. ✨
The last change needed to distribute the Network Controller functions is giving each site a portion of the unique numbers to hand out via its UNIQUE operation 🌸 I'll talk more about this below 🧚
To make it clear how the distributed Network Controller works, here's an example 💜 the details of which process picks port numbers, and so on, are only exemplary and are not a standard specified as part of the IPC 🙈
Okay so, for two sites in the network, K and L, process A at site K wants to talk to process B at site L 🌈 process B has a RECEIVE ANY pending at port M.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ / \
/ \ / \
| | | |
| Process A | | Process B |
| | | |
\ / \ /
\ / RECEIVE--> port M /
\ / ANY \ /
\______/ \______/Process A, lucky for us, knows port M exists at site L 🍓 so it sends a message using the SEND FROM ANY operation from port N to port M. The message has two port numbers in it, plus instructions for process B to SEND messages for process A to port P from port Q 🎀 site K's site number gets tacked onto the message, along with the message's SEND port N.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ / \
/ \ / \
| | | |
| Process A | | Process B |
| | | |
\ port N / \ port M /
\ /--->SEND FROM --->\ /
\ / ANY \ /
\______/ \______/
to port M, site L
containing K,N,P, & QProcess A now runs a RECEIVE at port P from port Q 💅 and it specifies site L as the rendezvous site.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ Rendezvous/ \
/ \ table \
| | | |
| Process A | ^ | Process B |
| | | | |
\ port P / | \ /
\ / | \ /
\ / <--RECEIVE __/ \ /
\______/ MESSAGE \______/
to site L
containing P, Q, & KA RECEIVE message goes from site K to site L and gets entered in the rendezvous table at site L ✨ later on, process B runs a SEND to port P from port Q, and specifies site L as the rendezvous site 😭
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ Rendezvous/ \
/ \ table \
| | | |
| Process A | | Process B |
| | | |
\ port P / <--------- port Q /
\ / \ /
\ / SEND \ /
\______/ \______/
to site L
containing P & QNow they're rendezvoused 🦋 the rendezvous table gets cleared, and the transmission to port P at site K happens. The SEND site number (and maybe the SEND port number too) gets tacked onto the transmission messages so the receiving process can see who sent them 👑
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ / \
/ \ / \
| | | |
| Process A | | Process B |
| | | |
\ port P / \ port Q /
\ /<--transmission<--\ /
\ / \ /
\______/ to port P, site K \______/
containing data and LProcess B might also want to run a RECEIVE from port N at port M at the same time 🌸
Here's the thing to notice: there's only one important control message in this system that moves between sites, the kind of message the paper calls a Host/Host protocol message in [2] 💖 that control message is the RECEIVE message. There are two other possible intersite control messages: an error message back to the originating site when a RECEIVE or SEND times out, and the SEND message for the rare case where the rendezvous site isn't the SEND site 😭 there also has to be a standard format for messages between ports. For example, something like this:
_________________ __________________ _____________
| rendezvous site | <6> | destination site | | source site |
|-----------------| |------------------| |-------------|
| RECEIVE port | | RECEIVE port | | RECEIVE port|
|-----------------| |------------------| |-------------|
| SEND port | | SEND port | | SEND port |
|-----------------| |------------------| |-------------|
| | | source site | | |
| | |------------------| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| data | | data | | data |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
|_________________| |__________________| |_____________|
transmitted transmitted received
by SEND by Network by RECEIVE
process Controller processIn the model time-sharing system it was possible to pass a port from process to process 🧚 and that's still possible with a distributed Network Controller ✨
Remember that, for a message to go from one process to another, a SEND to port M from port N and a RECEIVE at port M from port N must rendezvous, normally at the SEND site 🫶 both processes keep track of where they think the rendezvous site is, and they pass that site in as a parameter to the right operations. The RECEIVE process thinks it's the SEND site too 🙈 once a SEND and a RECEIVE rendezvous, the transmission goes to the source of the RECEIVE, and the rendezvous table entry is cleared and has to be set up again for every further transmission from N to M. So it's really easy for a RECEIVE port to move 🦋 if a process sends both the port numbers and the rendezvous site number to a new process at some other site, and that new process runs a RECEIVE using those same old port numbers and rendezvous site specification, the SENDer never finds out the RECEIVEr moved 😭 it's a bit harder for a send port to move 💀 but if it does, the pair of port numbers that was being used for a SEND, plus the original rendezvous site number, get passed to the new site. The process at the new SEND site names the old rendezvous site on the first SEND from the new site. The RECEIVE process will still think the rendezvous site is the old site, so the SEND and RECEIVE meet at the old site 🌈 when they meet, the table entry at that site gets cleared, and both the SEND and RECEIVE messages get sent to the new SEND site, just like they were headed there in the first place. Then the SEND and RECEIVE meet again at the new rendezvous site, and transmission carries on like the port never moved 👑 since every transmission includes the source site number, further RECEIVEs will be sent to the new rendezvous site ✨ you can figure out that this special handling is needed because a SEND message shows up at a site that didn't originate it<7> 💅 and note that the SEND port and the RECEIVE port can move at the same time 🎀
Of course, all of this could've also been done if the processes sent messages back and forth announcing any possible moves and the new site numbers 💖
A problem that probably popped into your head is how the SEND and RECEIVE buffers get matched for size 🫠. The easiest fix would be to require every buffer to have a common size, but ngl that's a hard no 🙅♀️, because it doesn't stretch to the case where processes in autonomous operating systems are trying to talk to each other 😭. A second option is for the processes to pass messages that specify buffer sizes. If we go that route, any excess data the SEND process sends that won't fit into the RECEIVE buffer gets discarded, and the RECEIVE process gets notified 🦋. It's giving simple, and I'm obsessed 😍. A third option is for the RECEIVE buffer size to be passed to the SEND site along with the RECEIVE message. Then the SEND process either gets notified when too much data is sent, or gets handed the RECEIVE buffer size outright 🎀. This last method would also let the Network Controller at the SEND site split one SEND into two or more SENDs, if that's what it takes to match a smaller RECEIVE buffer size 🧚.
Unique numbers get messy too 🌸 once the processes are geographically distributed. Three solutions are presented here. In the first, the autonomous operating systems ask the Network Controller for the unique numbers originally, and then guarantee the integrity of any unique numbers currently owned by local processes and programs, using whatever means the operating system has at its disposal. In this case the Network Controller would provide a way for a unique number to be sent from one site to another, and it would vouch for the number's identity at the new site 🫶. The second method is to simply hand the unique numbers to the processes using them. This depends on the non-malicious behavior of the processes to preserve the unique numbers, or, if an accident happens, on the two passwords (SEND and RECEIVE port numbers) that are required to initiate a transmission 🔐. If the unique numbers are given out in a non-sequential manner and are reasonably long (say 32 bits), there is little danger 💜. In the final method, a user identification is included in the port numbers, and the individual operating systems guarantee the integrity of these identification bits. So a process, while not able to be sure that the correct port is transmitting to him, can be sure that some port of the correct user is transmitting 👑. This is the so-called virtual net concept suggested by W. Crowther [2].<8>
A third difficult problem shows up when remote processes want to communicate: keeping high bandwidth connections going between them 🚀. The solution is to let the processes know a lot about the state of an on-going transmission. Let's look at a SEND process first. When a process executes a SEND, the local portion of the Network Controller passes the SEND on to the rendezvous site, which is normally the local site. When a RECEIVE arrives that matches a pending SEND, the Network Controller notifies the SEND process by causing an interrupt to the specified restart location. At the same time, the Network Controller starts shipping the SEND buffer to the RECEIVE site. When the transmission is complete, a flag is set that the SEND process can test 🚩. While a transmission is taking place, the process may ask the Network Controller to perform other operations, including other SENDs. A second SEND over a pair of ports already in the act of transmission is noted, and it becomes active as soon as the first transmission is complete. A third identical SEND results in an error message to the SENDing process ⚠️. Next, let's look at a RECEIVE process. When a process executes a RECEIVE, the RECEIVE is sent to the rendezvous site. When data resulting from this RECEIVE starts to arrive at the RECEIVE site, the RECEIVE process is notified via an interrupt to the specified restart location. When the transmission is complete, a flag is set that the RECEIVE process can test. A second RECEIVE over the same port pair is allowed. A third results in an error message to the RECEIVE process 🙈. So honestly there's enough machinery for a pair of processes to always have a transmission in progress and the next one pending 🔥. That means no efficiency is lost. On the other hand, each transmission must be preceded by a RECEIVE into a specified buffer, which keeps complete flow control locked in 🔒✨.
4. A Potential Application ✨
Only one resource sharing computer network currently exists, and that's the ARPA Computer Network 🌈. In this section I talk about applying the system described in this paper to the ARPA Network [2][5][9].
The ARPA Network currently has ten sites spread across the United States 🇺🇸. Each site consists of one to three (potentially four) independent computer systems called Hosts, plus one communications computer system called an IMP. All of the Hosts at a site are directly connected to the IMP. The IMPs themselves are connected together by 50-kilobit phone lines (much higher rate lines are a potential), although each IMP is connected to only one to five other IMPs 📞. The IMPs provide a communications subnet that the Hosts use to communicate. Data is sent through the communications subnet in messages of arbitrary size (currently about 8000 bits) called network messages 📦. When a network message is received by the IMP at the destination site, that IMP sends an acknowledgment, called a RFNM, back to the source site 💌.
A system for interprocess communication for the ARPA Network (let's call this IPC for ARPA) is currently being designed by the Network Working Group, under the chairmanship of S. Crocker of UCLA. Their design is somewhat constrained by the communications subnet [5]<9> 🧩. I'd love to compare IPC for ARPA point-by-point with the one developed in this paper. But that would first need a description, almost from scratch, of the current state of IPC for ARPA, since very little up-to-date information about it appears in the open literature [2]. Also, IPC for ARPA is quite complex, and the working documents describing it now run to many hundreds of pages, which makes any description lengthy and inappropriate for this paper 📚.<10> So I'll only make a few scattered comparisons between the two systems, and the first of them is implicit in this paragraph 👀.
The interprocess communication system being developed for the ARPA Network comes in several almost distinct pieces: the Host/IMP protocol, the IMP/IMP protocol, and the Host/Host protocol 🧃. The IMPs have sole responsibility for correctly transmitting bits from one site to another. The Hosts have sole responsibility for making interprocess connections. Both the Host and the IMP are concerned with flow control and message sequencing, and each takes a little responsibility for it 🤝. Applying the interprocess communication system described in this paper leads me to a different allocation of responsibility. The IMP still moves bits from one site to another correctly, but the Network Controller also lives in the IMP, and flow control is completely in the hands of the processes running in the Hosts, although they use the mechanisms the IMPs provide 🎯.
The IMPs provide the SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY, and UNIQUE operations, in slightly altered forms, for the Hosts. They also maintain the rendezvous tables, including moving SEND ports when necessary 🗂️. Putting these operations in the IMP means the Host/Host protocol program only has to be written once, rather than many times as is currently being done in the ARPA Network 🙌. It's useful to step through the five operations again 💫.
SEND. The Host gives the IMP a SEND port number, a RECEIVE port number, the rendezvous site, and a buffer specification (e.g., start and end, or beginning and length). The SEND is sent to the rendezvous site IMP, which is normally the local IMP. When a matching RECEIVE arrives at the local IMP, the Host is notified of the RECEIVE port of the message that just arrived. This port number is enough to identify the SENDing process, although a given operating system may have to keep internal tables that map this port number to a useful internal process identifier 🪪. At the same time, the IMP starts asking the Host for specific pieces of the SEND buffer and sends those pieces as network messages to the destination site. If a RFNM isn't received for too long, which implies a network message has been lost in the network, the Host is asked for the same data again and it gets retransmitted 🔁.<11> Except for the last piece of a buffer, the IMP requests pieces from the Host that are common multiples of the word size of the source Host, the IMP, and the destination Host. This avoids mid-transmission word alignment problems 📐.
RECEIVE. The Host gives the IMP a SEND port, a RECEIVE port, a rendezvous site, and a buffer description. The RECEIVE message is sent to the rendezvous site. As the network messages making up a transmission arrive for the RECEIVE port, they are passed to the Host along with the RECEIVE port number (and perhaps the SEND port number), plus an indication to the Host of where to put this data in its input buffer 🗃️. When the last network message of the SEND buffer is passed into the Host, it gets marked accordingly, and the Host can then detect this 🏁. (It's conceivable that the RECEIVE message could also allocate a piece of network bandwidth while it makes its network traverse to the rendezvous site 🤔.)
RECEIVE ANY. The Host gives the IMP a RECEIVE port and a buffer descriptor. This works the same as RECEIVE, but it assumes the local site is the rendezvous site 🏠.
SEND FROM ANY. The Host gives the IMP RECEIVE and SEND ports, the destination site, and a buffer descriptor. The IMP requests and transmits the buffer as fast as possible 🏎️. A SEND FROM ANY for a non-existent port is discarded at the destination site 🗑️.
In the ARPA Network, the Hosts are required by the IMPs to physically break their transmissions into network messages, and successive messages of a single transmission must be delayed until the RFNM is received for the previous message 🐢. In the system described here, RFNMs are tied to the transmission of a particular piece of buffer. The Hosts let the IMPs reassemble buffers in the Hosts by having the IMP tell the Host where to put each buffer piece. So pieces of a single buffer can be transmitted in parallel network messages, and several RFNMs can be outstanding at the same time ⚡. This enables the Hosts to deal with transmissions of more natural sizes and gives higher bandwidth for a single transmission 💪.
For additional efficiency, the IMP might know the approximate time it takes for a RECEIVE to get to a particular other site, and warn the Host to wake up a process shortly before the arrival of a message for that process is imminent ⏰.
5. Conclusion 🎓
Since the system described in this paper has not been implemented, I have no clearly demonstrable conclusions and no performance reports 🙃. Instead, I conclude with four openly subjective claims 💭.
- The interprocess communication system described in Section 2 is simpler and more general than most existing systems of equivalent power, and it is more powerful than most intra time-sharing system communication systems currently available 👑✨.
- Okay so time-sharing systems built like the model in Section 2 should be studied by designers who might see a computer network in their future. The structure seems to make joining a network super easy, honestly 🫶
- As computer networks get more common, remote interprocess communication systems like the one in Section 3 need to be studied 🌐 The system being built for ARPA is, in my opinion, a step in the wrong direction 🙈 It's focused more on communication between monitors than on communication between processes, and that ends up undercutting convenient resource sharing 💀
- The application in Section 4 is way simpler to implement and more powerful than the system currently being built for the ARPA Network. I really suggest that the ARPA Network seriously consider adopting my method 👑✨
Footnotes 🎀
- Almost any of the common definitions of a process would work for what this paper needs 💜
- Or maybe there's only one permanently known port 🚪 It belongs to a directory-process that keeps a table of permanent-process/well-know-port associations 🗂️
- That program that prints file directories, tells you who's on other teletypes, runs subsystems, etc. 💅
- Okay, by now you've probably noticed that I'm not a fan of starting up a brand-new process (a fresh conceptual copy of a program) every time another user wants to use the program 🙅♀️ I'd rather think of the program as one single process that knows it's being used by lots of other processes at once. It juggles them, or makes users wait until it can get around to them 🧚
- I say operating system instead of time-sharing system in this section 🌸 That's because the autonomous systems at the network nodes could be full-blown time-sharing systems in their own right, or an individual process in a bigger, geographically distributed time-sharing system, or just autonomous sites that want to talk to each other 🦋
- For a
SEND FROM ANYmessage, the rendezvous site is the destination site 📍 - If you know the old re-connection scheme for the ARPA Network, this system is comparatively simple 😌 There are no permanent connections to break and move. Connections only exist fleetingly here, so they can be remade between any pair of processes that happen to know each other's port numbers and have some clue where they each are 🎀
- Crowther says this is not the virtual net concept 🤭
- As one of the builders of the ARPA communications subnet, I'm partially responsible for these constraints 🫠
- If you have access to the ARPA working documents, you might want to read Specifications for the Interconnection of a Host to an IMP, BBN Report No. 1822; and ARPA Network Working Group Notes #36, 37, 38, 39, 42, 44, 46, 47, 48, 49, 50, 54, 55, 56, 57, 58, 59, 60 📚
- This also allows messages to be completely thrown away by the IMP subnet it that should ever be useful 🗑️
References 📚
- Ackerman, W., and Plummer, W. An implementation of a multi-processing computer system. Proc. ACM Symp. on Operating System Principles, Gatlinsburg, Tenn., Oct. 1-4, 1967.
- Carr, C. Crocker, S., and Cerf, V. Host/Host communication protocol in the ARPA network. Proc. AFIPS 1970 Spring Joint Comput. Conf., Vol. 36, AFIPS Press, Montvale, N.J., pp. 589-597.
- Dennis, J., and VanHorn, E. Programming semantics for multiprogrammed computations. Comm. ACM 9, 3 (March, 1966), 143-155.
- Hansen, P.B. The nucleus of a multiprogramming system. Comm. ACM 13, 4 (April, 1970), 238-241, 250.
- Heart, F., Kahn, R., Ornstein, S., Crowther, W., and Walden, D. The interface message processor for the ARPA computer network. Proc. AFIPS 1970 Spring Joint Comput. Conf., Vol. 36, AFIPS Press, Montvale, N.J., pp. 551-567.
- Lampson, B. SDS 940 Lectures, circulated informally.
- _______. An overview of the CAL time-sharing system. Computer Center, University of California, Berkeley, Calif.
- _______. Dynamic protection structures. Proc. AFIPS 1969 Fall Joint Comput. Conf., Vol. 35, AFIPS Press, Montvale, N.J., pp. 27-38.
- Roberts, L., and Wessler, B. Computer network development to achive resource sharing. Proc. AFIPS 1970 Spring Joint Comput. Conf., Vol. 36, AFIPS Press, Monvale, N.J., pp. 543-549.
- Spier, M., and Organick, E. The MULTICS interprocess communication facility. Proc. ACM Second Symp. on Operating Systems Principles, Princeton University, Oct. 20-22, 1969.
Author's Address 🦋
D. C. Walden
Bolt Bernakek and Newman, Inc.
Cambridge, Massachusetts[ This RFC was put into machine readable form for entry into the online RFC archives by Adam Costello 3/97 ] 🌈
📦 where this page comes from
- ietf: rfc62 1970-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms