4. A Potential Application

Only one resource sharing computer network currently exists, the ARPA Computer Network. In this section, I discuss application of the system described in this paper to the ARPA Network [2][5][9].

The ARPA Network currently incorporates ten sites spread across the United States. Each site consists of one to three (potentially four) independent computer systems called Hosts and 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 through which the Hosts 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, to the source site.

A system for interprocess communication for the ARPA Network (let us 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 would like to compare point-by-point IPC for ARPA with the one developed in this paper; however, such a comparison would first require description here, almost from scratch, of the current state of IPC for ARPA since very little up-to-date information about IPC for ARPA appears in the open literature [2]. Also, IPC for ARPA is quite complex and the working documents describing it now run to many hundred pages, making any description lengthy and inappropriate for this paper.<10> Therefore, I shall make only a few scattered comparisons of the two systems, the first of which are implicit in this paragraph.

The interprocess communication system being developed for the ARPA Network comes in several almost distinct pieces: The Host/IMP protocol, 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 IMP are concerned and take a little responsibility for flow control and message sequencing. Applications of the interprocess communication system described in this paper leads me to make a different allocation of responsibility. The IMP still continues to move bits from on site to another correctly but the Network Controller also resides in the IMP, and flow control is completely in the hands of the processes running in the Hosts, although using the mechanisms provided by the IMPs.

The IMPs provide the SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY, and UNIQUE operations in slightly altered forms for the Hosts and also maintain the rendezvous tables, including moving of SEND ports when necessary. Putting these operations in the IMP requires the Host/Host protocol program to be written only once, rather than many times as is currently being done in the ARPA Network. It is perhaps 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, normally the local IMP. When a matching RECEIVE arrives at the local IMP, the Host is notified of the RECEIVE port of the just arrived message. This port number is sufficient to identify the SENDing process, although a given operating system may have to keep internal tables mapping this port number into a useful internal process identifier. Simultaneously, the IMP begins to ask the Host for specific pieces of the SEND buffer, sending these pieces as network messages to the destination site. If a RFNM is not received for too long, implying a network message has been lost in the network, the Host is asked for the same data again and it is retransmitted.<11> Except for the last piece of a buffer, the IMP requests pieces from the Host which are common multiplies of the word size of the source Host, IMP, and 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 RECEIVE port number (and perhaps the SEND port number), and an indication to the Host where to put this data in its input buffer. When the last network message of the SEND buffer is passed into the Host, it is marked accordingly and the Host can then detect this. (It is conceivable that the RECEIVE message could also allocate a piece of network bandwidth while making 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 assumes the local site to be 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, since RFNMs are tied to the transmission of a particular piece of buffer and since the Hosts allow the IMPs to reassemble buffers in the Hosts by the IMP telling the Host where to put each buffer piece then pieces of a single buffer can be transmitted in parallel network messages and several RFNMs can be outstanding simultaneously. This enables The Hosts to deal with transmissions of more natural sizes and 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.