RFC 61
Note on Interprocess Communication in a Resource Sharing Computer Network
Part 1 of 4 ✨
Network Working Group 🎀 Request for Comments: 61 📄 Author: Dave Walden, from Bolt Beranek and Newman 💖 Date: July 17, 1970 🗓️
okay so the title block tells us who wrote this (Dave Walden at Bolt Beranek and Newman), when (July 17, 1970), and that it's RFC 61. it doesn't list a category, a status, or anything it obsoletes or updates, so we're not inventing any of that 🙈
A Note on Interprocess Communication in a Resource Sharing Computer Network 🦋
bestie, this is a draft 📝. Dave says it's a study he's still working on, and it might be interesting to other people in the network.
Interprocess Communication in a Resource Sharing Computer Network 🌸
Introduction 🧚
okay so the first thing Dave does is quote a definition 🫶. A resource sharing computer network is "a set of autonomous, independent computer systems, interconnected so as to permit each computer system to utilize all of the resources of each other computer system." 🔥 The vibe is that a program running on one computer should be able to call on the resources of the other computers, kind of like calling a subroutine. Roberts and Wessler explain this definition and why a network like this is worth wanting in [1] 👑
there are two ways resource sharing can happen 💅. One is pairwise and ad hoc, where every pair of computers works out its own deal. The other is a systematic, network-wide standard. This paper builds one possible network-wide system for resource sharing ✨
Dave thinks resources are naturally tied to processes [2] 💜, so the big problem of resource sharing is really the problem of interprocess communication. He also agrees with Carr, Crocker, and Cerf [3] that interprocess communication over a network is a subcase of general interprocess communication in a multiprogrammed environment 🌈
these views are everywhere in the study 💖, and it's split into two parts 🎀. First, Dave builds a model of a time-sharing system that has capabilities especially good for interprocess communication. Then he shows that those capabilities can be used in a general way that lets processes spread across a computer network talk to each other 🦋
this note pulls from lots of sources 🍓. The most influential ones were: 1) an early sketch of a Host protocol for the ARPA Network [1][3][4] by W. Crowther of Bolt Beranek and Newman Inc. (BBN) and S. Crocker of UCLA; 2) Ackerman and Plummer's paper on the MIT PDP-1 time sharing system [5]; and 3) talks with R. Kahn of BBN about Host protocol, message control, and routing for the ARPA Network. Dave hopes there are some original ideas in here too ✨ But he's the one who put all these ideas together into the system described here, so any inconsistencies or bugs in it are his responsibility 🙈
one more important thing ⭐: this note does not represent an official BBN position on Host protocol for the ARPA Computer Network.
A Model for a Time-Sharing System 🧚♀️
this section describes a model time-sharing system that Dave thinks is especially good for interprocess communication 💅. The basic structure of this model is not original, though. It comes from [5][9] 📚
the model has two pieces: the monitor and the processes 🎀. The monitor does a bunch of jobs. It switches control from process to process when appropriate (for example, when a process has used "enough" time or when an interrupt happens). It manages core memory and the swapping medium, controls how control passes from one process to another (that's the protection mechanisms), creates processes, takes care of sleeping processes, and more 🦋
the processes do most of the stuff that's normally thought of as supervisor functions in a time-sharing system (system processes), plus all the normal user stuff (user processes) 💖. A typical system process is the disc handler or the file system. For efficiency, it can help to think of system processes as being locked in core 🔥
a process can ask the monitor to do several things 💅: start another, equal, autonomous process (basically load a program, or find a shareable copy of one somewhere, start it, and pass it some initial parameters); halt the running process; put the current process to sleep until a specified event; send a message to a specified process; become available to receive a message from a specified process; become available to receive a message from any process; send a message to a process that can receive from any process; and request a unique number. Dave says there should probably be other monitor functions too 🌈 He also leaves it as an exercise for the reader to convince themselves that whatever monitor they're stuck with can provide these functions. Most of them can 😭
Dave isn't going to worry about protection here 🙈. He just assumes all the processes are "good" processes that never make any mistakes. If you want a protection structure in mind while reading, the _capability_ system described in [5][6][7][8] is a great fit 🫶
now let's look a little closer at the eight operations listed above that a process can ask the monitor to perform 👑
START. 🚀 This operation starts another process. It has two parameters: some kind of identification for the program to be loaded, and a parameter list for that program. Once the program is loaded, it starts at its given entry point and gets its parameter list in some well-known way. The process keeps existing until it halts itself.
HALT. 💤 This operation puts the currently running process to sleep until some event finishes. It has one parameter, the event to wait for. Sample events are a hardware interrupt arriving or a message arriving from another process. The process restarts at the instruction after the SLEEP command. The monitor never puts a process to sleep on its own, except when the process overflows its quantum.
RECEIVE. 📥 This operation lets another process send a message to this process. It has four parameters: the port (defined below) waiting for the message, the port the message will be accepted from, a specification of the buffer available to receive the message, and a location to transfer to when the transmission is complete. [In other words, an interrupt location. Any message port can be used to allow interrupts, event channels, etc. The user programs whatever they want. 🫶]
SEND. 📤 This operation sends a message to some other process. [I suppose a process could also send a message to itself. 🙈] It has four parameters: a port to send the message to, the port the message is being sent from, the message itself, and a location to transfer to when the transmission is complete.
RECEIVE ANY. 📬 This operation lets any process send a message to this process. It has four parameters: the port waiting for the message, the buffer available to receive the message, a location to transfer to when the message is received, and a location where the port that sent the message may be noted.
SEND FROM ANY. 🦋 This operation lets a process send a message to a process that can receive a message from any process. It has the same four parameters as SEND. Dave will talk about why this operation is needed below 👀
UNIQUE. 🔢 This operation gets a unique number from the monitor.
a _port_ is a particular data path to or from a process 🌈. Every port has a unique number that identifies it. Ports are used to send messages from one process to another like this 💖. Imagine two processes, A and B, that want to talk. Process A runs a RECEIVE at port N from port M. Process B runs a SEND to port N from port M. The monitor matches up the port numbers and moves the message from process B to process A 🎀. As soon as the buffer has been fully sent out of process B, process B restarts at the location given in its SEND operation. As soon as the message is fully received at process A, process A restarts at the location given in its RECEIVE operation. How the processes figure out the right port numbers to talk to each other isn't the monitor's problem. That one's left to the processes 🧚
now for an example, which is honestly so iconic 💅🔥. Say the model time-sharing system starts up with several processes always running. These permanent processes also have some universally known, permanently assigned ports. [Or maybe there's just one permanently known port, belonging to a directory-process that keeps a table of permanent-process/well-known-port associations. 📒] Suppose two of the permanently running processes are the logger-process and the teletype-scanner-process. When the teletype-scanner-process first starts running, it goes to sleep waiting for an interrupt from the hardware teletype scanner 😴. The logger-process starts out sleeping too, waiting for a message from the teletype-scanner-process through its well-known permanent SEND and RECEIVE ports 💤
the teletype-scanner-process keeps a table indexed by teletype number. Each entry holds a port to send characters from that teletype to, and a port to receive characters for that teletype on 🖨️. If a character arrives (which wakes up the teletype-scanner-process) and the process has no entry for that teletype, it asks the monitor for a pair of unique numbers (using UNIQUE). Then it sends a message containing that pair to the logger-process, using the ports the logger-process is known to have a RECEIVE pending on 📨. [Actually, the scanner process could always use the same pair of port numbers for a particular teletype, as long as they were only handed to one copy of the executive at a time. 🙈] The scanner-process also writes the pair of numbers into the teletype table, and sends that teletype's characters, and all future ones, to the port with the first number, from the port with the second number 💅. The scanner-process probably also hands the logger-process a second pair of unique numbers for teletype output, and does a RECEIVE using those numbers 🎀
when the logger-process gets the message from the scanner-process, it starts up a copy of what SDS 940 TSS [12] users call the executive 🧑💻. That's the program that prints file directories, tells you who's on other teletypes, runs subsystems, and so on. It passes this copy of the executive the port numbers, so the executive-process can also do its in's and out's to the teletype using those ports ✨. If the logger-process wants to get a job number and password from the user, it can use the port numbers to talk to the user for a bit before handing them over to the executive 🔐💜
_Port numbers_ are passed around among processes all the time 💅 and every once in a while a port gets handed off to a different process entirely 🦋. Here's the crucial part: once a process gives a _port_ away, the first process has to stop using it, periodt 🙈. We could add a mechanism to enforce that, and the protected object system of [8] is one such mechanism ✨. [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 is prima facie evidence of the 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 all of the autonomous time-sharing system in a network would adopt this protection mechanism. If this assumption cannot be made, it seems more practical to require both port numbers.] 🧚
Somewhere in the monitor there has to be a table of port numbers linked to processes and restart locations 📋. The table entries get cleared after each SEND/RECEIVE match is made 🧹. Also, if a process is running (maybe asleep) and has a RECEIVE ANY pending, then any process that knows the receive port number can talk to it directly, no loggers or any of that drama 🫶. This is obviously essential inside a local time-sharing system, and it seems super useful in a bigger network if the dream of resource sharing is ever going to happen 🌈.
When a SEND gets executed, nothing happens until a matching RECEIVE gets executed too 🎀. If a proper RECEIVE doesn't show up for a while, the SEND times out and the SENDing process gets notified 😭. If a RECEIVE gets executed but the matching SEND doesn't happen for a long time, the RECEIVE times out and the RECEIVing process gets notified instead 💀.
A RECEIVE ANY never times out, but it can be taken back 🔄. A SEND FROM ANY message is always sent immediately, and it gets discarded if no proper receiver exists 🗑️. No error message comes back, and any acknowledgment is up to the processes themselves 🤷♀️. If the table where SENDs and RECEIVEs get matched up ever overflows, a process that originates a further SEND or RECEIVE gets notified, exactly as if its SEND or RECEIVE had timed out 🚨.
Generally, well-known, permanently assigned ports get used through RECEIVE ANY and SEND FROM ANY 👑. These permanent ports are mostly used for starting processes going, so not much data travels through them 🌸.
Okay, next example, and this one's a demo of the FORTRAN compiler 💖. We already covered how a user sits down at their teletype and gets connected to an executive ⌨️. So we pick up from there. The user types in and out of the executive, which is busy doing SENDs and RECEIVEs ✨. Eventually the user types RUN FORTRAN, and the executive asks the monitor to start a copy of the FORTRAN compiler 🏃♀️. It passes FORTRAN the two ports the executive was using to talk to the teletype as start-up parameters 🎁. FORTRAN is expecting those parameters, so it does SENDs and RECEIVEs on those ports to figure out which input and output files the user wants 🕵️♀️. FORTRAN types INPUT FILE? to the user, who responds F001 🙋♀️. Then FORTRAN sends a message to the file-system-process, which is asleep waiting for something to do 😴. The message goes through well-known ports and asks the file system to open F001 for input 📨. It also includes a pair of ports 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 a message back to FORTRAN with the ports FORTRAN can use to read the file 📂. The exact same procedure happens for the output file 🔁. When the compilation is done, FORTRAN hands the teletype port numbers 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 once it has nothing else to do 💤.
[The reader should have noticed by now that I do not like to think of a new process (consisting of a new conceptual copy of a program) being started up each time another user wishes to use the program. Rather, I like to think of the program as a single process which knows it is being used simultaneously by many other processes and consciously multiplexes among the users or delays service to users until it can get around to them.] 🧠💜
Again, the file-system-process can keep a small collection of port numbers and reuse them over and over, as long as file system users give the port numbers back when they're done with them 🔄. Of course, once that collection has eventually dribbled away, the file system can grab some new unique numbers from the monitor 🌟.
Note that when two processes want to communicate, they set up the connection themselves, and they can do it in whatever mutually convenient way works for them 🤝. For instance, they can swap port numbers, or one process can pick all the port numbers and tell the other process which ones to use 🎯. Of course, in a particular implementation of a time-sharing system, the builders might choose to restrict how processes execute SENDs and RECEIVEs, and they might forbid passing port numbers around freely, requiring instead that the monitor (or some other special program) be called to do these jobs 🚧.
Flow control in this system is handled in the simplest way possible: a SEND from a process never starts until the receiver executes a RECEIVE 🛑➡️. Of course, interprocess messages can still fly back and forth suggesting that a process stop sending, or that space be allocated, and so on 💬.
INTERPROCESS COMMUNICATION BETWEEN REMOTE PROCESS
The system from the previous section extends easily to let processes at geographically different locations talk to each other, like within a computer network 🌐✨.
Let's start with a simple setup: processes spread around the points of a star ⭐. Each point of the star is an autonomous time-sharing system 🏫. At the center sits a rather large, smart computer system called the Network Controller 👑. No processes run on this center system. Instead, think of it as an extension of the monitor of each time-sharing system in the network 🧠.
It should be obvious that if the Network Controller can perform the operations SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY, and UNIQUE, AND all the monitors in all the time-sharing systems in the network hand these operations off to the Network Controller instead of doing them themselves, then we've solved interprocess communication between remote processes 🎉. We don't need any other changes 💅.
Why does everything keep working once we add the Network Controller? Because it can keep track of which RECEIVEs and which SENDs have been executed, and match them up just like the monitor did in the model time-sharing system 🔗. A networkwide port numbering scheme is also possible, with the Network Controller knowing where (that is, at which site) a particular port is at any given time 📍.
Next, consider a more complex network with no common center point. That means the functions the Network Controller performs have to be spread out among the network nodes 🌸. In the rest of this section I'll show that it's possible to distribute the Network Controller's functions across the many network sites efficiently and conveniently, while still enabling general interprocess communication between remote processes 🦋💖.
Each of the four SEND/RECEIVE operations described above needs some changes to work in a distributed network 🛠️. RECEIVE gets a new parameter that specifies the site the RECEIVE is sent to 📮. SEND FROM ANY and SEND get a site to send the SEND to, though that's normally the local site 🏠. Both RECEIVE and RECEIVE ANY also get the ability to obtain the source site of any received message 🗺️. So when a RECEIVE is executed, it's sent to the specified site, which might be remote 🛰️. At the same time, a SEND gets sent to that same site, which is normally the local site of the process doing the SEND 📤. At this site, called the rendezvous site, the RECEIVE is matched with the proper SEND, and the message transmission is allowed to go ahead to the site the RECEIVE came from 🥳.
A RECEIVE ANY never leaves its originating site, and that's exactly why SEND FROM ANY is needed 🙌. It has to be possible to send a message to a RECEIVE ANY port without the message getting stuck waiting for a RECEIVE at the sending site 💨. Sure, we could build the system so the SEND/RECEIVE rendezvous happens at the RECEIVE site, and then skip SEND FROM ANY entirely 🤔. But in my judgment, being able to block a normal SEND transmission at the source site more than makes up for the extra complexity 💯.
Somewhere at each site, a rendezvous table is kept 📚. This table has an entry for each unmatched SEND or RECEIVE received at that site, plus an entry for every RECEIVE ANY given at that site 📝. A matching SEND/RECEIVE pair is cleared from the table as soon as the match happens, or maybe when the transmission is complete ✅. Just like the similar table in the model time-sharing system, SEND and RECEIVE entries time out if they stay unmatched for too long, and the originator gets notified ⏰. RECEIVE ANY entries get cleared from the table 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 through its UNIQUE operation 🎟️. I'll talk more about this topic 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 system 🙃.
Suppose there are 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 |
| | | |
| | | |
\ / \ /
\ / \ port M /
\________/ \____^___/
|
RECEIVE ANYProcess A, fortunately, knows that port M exists at site L 🥰. Process A sends messages using the SEND FROM ANY operation, going from port N to port M 📨. The message contains two port numbers, plus instructions for process B to SEND messages back to process A, to port P, from port Q 🔁. Site K's site number gets appended to this message, along with the message's SEND port N 🏷️✨.
Okay so picking up right where we left off 💅
to port M, site L
containing K, N, P, & QProcess A now executes a RECEIVE at port P from port Q. Process A specifies the rendezvous site to be site L. 🦋
SITE K SITE L
________ R ________
/ \ e / \
/ \ n T/ \
/ \ d a \
| | e b Process B |
| Process A | z l |
| | v e |
\ / o \ /
\ port P / RECEIVE ---> u \ /
\________/ MESSAGE s \________/
to site L
containing P, Q, & KSo a RECEIVE message gets sent from site K to site L and lands in the rendezvous table at site L. 📬 Then, at some other time, process B executes a SEND to port P from port Q, specifying site L as the rendezvous site. ✨
SITE K SITE L
________ R ________
/ \ e / \
/ \ n T/ \
/ \ d a \
| | e b Process B |
| Process A | z l |
| | v e |
\ / o \ /
\ port P / u <--- port Q /
\________/ SEND s \________/
to site L
containing P & QAnd now they meet! 🎉 A rendezvous happens, the rendezvous table entry gets cleared, and the transmission to port P at site K goes through. The SEND site number (and maybe the SEND port number too) gets tacked onto the messages of the transmission, so the receiving process knows who sent it. 🫶
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ port P / \ port Q /
\ / <---- transmission <---- \ /
\________/ to port T, site K \________/
containing data and LProcess B might also want to execute a RECEIVE from port N at port M at the same time. 👀
Now here's the tea: there is only one important control message in this system that moves between sites, and it's the kind of message that gets called a Host/Host protocol message in [3]. That's the RECEIVE message, bestie. 🌸 There are two other possible intersite control messages too: an error message sent back to the originating site when a RECEIVE or SEND times out, and the SEND message in the rare case where the rendezvous site isn't the SEND site. 💀
Of course there also has to be a standard format for messages between ports. For example, something like this:
+-----------------+ +-----------------+ +-----------------+
| rendezvous site | | destination site| | source site |
+-----------------+ +-----------------+ +-----------------+
| RECEIVE port | | RECEIVE port | | RECEIVE port |
+-----------------+ +-----------------+ +-----------------+
| SEND port | | SEND port | | SEND port |
+-----------------+ +-----------------+ +-----------------+
| | | source port | | |
| | +-----------------+ | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| data | | data | | data |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+-----------------+ +-----------------+ +-----------------+
transmitted transmitted received
by SEND by Network by RECEIVE
process Controller processNote: for a SEND FROM ANY message, the rendezvous site is the destination site. 🍓
In 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. 🧚 (If you're not convinced port passing is useful, go read the section on reconnection in [11]. 🙈)
Remember this part, it's the main event 👑: 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 have to rendezvous, normally at the SEND site. Both processes keep track of where they think the rendezvous site is, and they hand that site over as a parameter of the right operations. The RECEIVE process thinks it's the SEND site, and the SEND process normally thinks it's the SEND site too. Once a SEND and a RECEIVE rendezvous, the transmission goes to the source of the RECEIVE, the rendezvous table entry is cleared, and it has to be set up again for every further transmission from N to M. Because of that, 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 executes a RECEIVE using those same old port numbers and rendezvous site specification, the SENDer never finds out the RECEIVEr moved. 😭✨
Moving a SEND port is a bit more work, but it's still doable. 💅 If one does move, the pair of port numbers that was being used for a SEND, along with the original rendezvous site number, get passed to the new site. The process at the new SEND site names the old rendezvous site in the first SEND it makes from the new site. The RECEIVE process still thinks 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, the rendezvous site number on the SEND message is changed to the site that originated the SEND message, and both the SEND and RECEIVE messages get sent to the new SEND site, just as if they'd been destined for it all along. The SEND and RECEIVE then meet again at the new rendezvous site, and transmission carries on like the port never moved at all. 🎀
Since every transmission carries the source site number, further RECEIVEs will be sent to the new rendezvous site. 🌈 And you can figure out that this special handling needs to happen because a SEND message shows up at a site that didn't originate it. 🔍
Everything is so easy to change because there are no permanent connections to break and move, like in the once-proposed reconnection scheme for the ARPA network [10][11]. Connections only exist fleetingly in the system described here, which means they can be remade between any pair of processes that happen to know each other's port numbers and have some clue where each one is. It's giving flexibility, periodt. 💖
Of course, all of this could have been done by having the processes send messages back and forth announcing any potential moves and the new site numbers. 🙄
REFERENCES 📚
[1] L. Roberts and B. Wessler, Computer Network Development to achieve Resource Sharing, Proceedings 1970 SJCC.
[2] V. Vyssotsky, F. F. Corbato, and R. Graham, Structure of the MULTICS Supervisor, Proceedings 1965 FJCC.
[3] C. Carr, S. Crocker, and V. Cerf, Host/Host Communication Protocol in the ARPA Network, Proceedings 1970 SJCC.
[4] F. Heart, et al, The Interface Message Processor for the ARPA Computer Network, Proceedings 1970 SJCC.
[5] W. Ackerman and W. Plummer, An Implementation of Multi-processing Computer System, Proceedings Gatlinburg Symposium on Operating System Principles.
[6] J. Dennis and E. Van Horn, Programming Semantics for Multiprogramming Computation, Proceedings of the San Dimes Conference on Programming Language and Pragmatics.
[7] B. Lampson, Dynamic Protection Structures, Proceedings FJCC 1969.
[8] B. Lampson, An Overview of the CAL Time-Sharing System, Computer Center, University of Calif., Berkeley.
[9] P. Hansen, The Nucleus of a Multiprogramming System, CACM, April 1970.
[10] S. Crocker, ARPA Network Working Group Note #36.
[11] J. Postel and S. Crocker, ARPA Network Working Group Note #48.
[12] B. Lampson, 940 Lectures.
APPENDIX: AN APPLICATION ✨
okay so the ARPA network is literally the only resource sharing computer network that exists right now 🌈, and in this appendix I'm gonna show that the system from this note can actually be applied to it 💅. There's already a whole mountain of work on interprocess communication in the ARPA network, and it comes in a few almost-separate pieces: the Host/IMP protocol, the IMP/IMP protocol, and the Host/Host protocol 🧚. I'm assuming you're already familiar with all that for the rest of this, but if you're lost, go check [See references [1][3][4][10][11]; Specifications for the Inter-connection of a Host to an IMP, BBN Report No. 1822; and ARPA Network Working Group Notes #37, 38, 39, 42, 44, 46, 47, 48, 49, 50, 54, 55, 56, 57, 56, 59.] 📚🎀
In the ARPA network, the IMPs have sole responsibility for correctly transmitting bits from one site to another, and the Hosts have sole responsibility for making interprocess connections. Both the Host and the IMP are concerned with flow control and message sequencing, and they each take a little responsibility for it 💖. Once you apply the interprocess communication system I've described, though, the responsibilities get split up differently 🔥. The IMP still correctly moves bits from one site to another, but the Network Controller also lives in the IMP, and flow control is completely in the hands of the processes running in the Hosts. (They might still use mechanisms provided by the IMPs, tho 🫶.)
The IMPs provide the SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY, and UNIQUE operations for the Hosts, just in slightly altered forms, and they also maintain the rendezvous tables, including moving SEND ports around when necessary 👑.
It's perhaps easiest to step through the five operations again, so let's do it bestie ✨.
SEND. The Host gives the IMP a SEND port number, a RECEIVE port number, the rendezvous site, and a buffer specification=20 (e.g., start and end, beginning and length). The SEND gets sent to the rendezvous site, which is normally the local site 🦋. When the matching RECEIVE arrives, the Host gets notified of the RECEIVE port of the just-arrived receive message. That port number is enough to identify the SENDing process, although a given time-sharing system might have to keep internal tables mapping this port number into useful internal process identifiers 🧠. At the same time, the IMP starts asking the Host for specific chunks of the data buffer, and those chunks get sent off to the destination as the IMP's RFNM control allows 🌸. If a RFNM isn't received for too long, which implies a message got lost in the network, the Host is asked for the same chunk of data again. (This also means messages can be completely thrown away by the IMP network if that should ever be useful 🙈.) The Host does have the option to abort the transmission at that point 💅. While a transmission is happening, the Host can ask the IMP to do other operations, including other SENDs 🍓. A second SEND over a pair of ports that's 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 Host 💀. And if a SEND times out, an error gets returned too 😭.
RECEIVE. The Host gives the IMP a SEND port, a RECEIVE port, a rendezvous site, and a buffer description. The RECEIVE message gets sent to the rendezvous site 🌈. When chunks of a transmission arrive for the RECEIVE port, they get passed to the Host along with the RECEIVE port number (and maybe the SEND port number too), plus an indication of where in its input buffer the Host should put the data 🎀. When the last piece of the SEND buffer is passed into the Host, it gets marked as the last one, and the Host can then detect that 🔥. A second RECEIVE over the same port pair is allowed. A third one results in an error message to the Host 🙃. The mechanism in this paragraph and the previous one lets a pair of processes always have both a transmission in progress and the next one pending, so no efficiency gets lost 👑. On the other hand, every transmission has to be preceded by a RECEIVE into a specified buffer, which gives you complete flow control 🫶. (It's conceivable that the RECEIVE message could allocate a piece of network bandwidth while it's traveling across the network 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 gets discarded at the destination site 🗑️.
RFNMs are tied to the transmission of a particular chunk of buffer, kinda like how acknowledgments are tied to packets now, and they perform the same function ✨. If the Hosts let the IMPs reassemble buffers in the Hosts (by having the IMP tell the Host where it should put a buffer chunk, as described above), then chunks of a single buffer can be transmitted in parallel, and several RFNMs can be outstanding at the same time 🌸. Packet reassembly is still done in the IMPs 💖.
A final operation has to be provided by the IMP: the UNIQUE operation 🔐. There are lots of ways to maintain unique numbers, and three are presented here 🍓.
The first possibility is for the Hosts to ask the IMPs 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 Host has at its disposal 👑. In this case, the IMPs would provide a method for a unique number to be sent from one host to another, and they would vouch for the number's identity at the new site 🫶.
The second method is to simply give the unique numbers to the processes that are using them 🦋. This depends on the processes behaving non-maliciously to preserve the unique numbers. And if an accident happens, there are the two passwords (the SEND and RECEIVE ports) that are required to initiate a transmission 🙈. If the unique numbers are given out in a non-sequential manner and they're reasonably long (say 32 bits), there's little danger 🌈.
In the final method, a user identification is included in the port numbers, and the individual time-sharing systems guarantee the integrity of these identification bits 🎀. So a process, while not able to be sure that the correct port is transmitting to it, can be sure that some port of the correct user is transmitting 🥹. This is the so-called virtual net concept suggested by W. Crowther [3] ✨.
Random Contents. Putting these operations in the IMP means the Host/Host protocol program only has to be written once, instead of many times like is currently being done in the ARPA Network 🧚. The IMPs can stop a specific host transmission (by not asking for the next chunk for a while) if that seems necessary to ease congestion problems in the communications subnet 🛑. And the IMP might know the approximate time it takes for a RECEIVE to get to a particular other site, and then warn the Host to wake up a process shortly before a message for that process is about to arrive ⏰💅.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Katsunori Tanaka 4/99 ]📦 where this page comes from
- ietf: rfc61 1970-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms