couple of disadvantages: In the simplest formulation, the RECEIVE had
to be waiting when the OUT+data arrived, otherwise the out data were
thrown away. This puts too tight a constraint on the timing of the
SEND and RECEIVE, especially since the sender and receiver processes
can be a continent apart. However, if the IN is allowed to arrive
first and must be held until matched by a RECEIVE, the monitor must
buffer an indeterminate amount of data in all cases including the
normal one. Further, basing everything on rendezvous at the
destination makes the process of moving a port difficult.
The next simplest MSP we considered was the IPC of reference 4. This
works just the opposite of the above described MSP in that it is
based on almost all rendezvous being done at the source Host with two
special messages to handle the relatively uncommon cases when a
rendezvous must be done at the destination or an intermediate Host.
This system, its advantages, and disadvantages is discussed at very
great length in the reference.
A third variation on the MSP, suggested by Crowther, is the same as
the present MSP in that the OUT and IN rendezvous at a process
specified rendezvous Host and the OUT is sent to the source of the IN
and the IN to the source of the OUT, but the data is not sent along
with the OUT. Instead, when the OUT finally reaches the source of
the IN, another message is sent from the receiver Host to the source
Host requesting the data to be sent. The data finally is transmitted
to the destination in response to this data request message. Our
main objection to this system is its lack of symmetry, but we do
recognize that it does not require any Host to buffer data for which
a process has not set up an input buffer and perhaps for that reason
it is a better system than the MSP we are presenting.
In the last MSP variation we considered, the difference between SEND
or RECEIVE and OUT or IN was discarded. In this case only one
message is used which we will call TRANSFER. When a process executes
a TRANSFER it can specify an input buffer, an output buffer, both, or
neither. Two processes wishing to communicate both execute TRANSFERs
specifying the same to and from port ids and the same rendezvous
Host. The TRANSFERs result in TRANSFER-messages plus data in the
case that an output buffer was specified which rendezvous at the
rendezvous Host. When the rendezvous occurs, the TRANSFER-messages
plus their data cross and each is sent to the source of the other.
The system allows processes not to know whether they must do a SEND,
or RECEIVE and is (perhaps) a nice generalization of the MSP
presented in this note. For instance, two processes can exchange
data using this system, or two processes can kind of interrupt each
other by sending dataless TRANSFERs. This variation of the MSP is a
development of a suggestion of Steve Crocker. Its disadvantages are:
(1) unintentional matches are more likely to occur, (2) rendezvous
selection site is more complex, and (3) it's hard to think about.
APPENDIX
A system for Interprocess Communication in a Resource Sharing
Computer Network. Communications of the ACM, April, 1972.
Permission to reprint this paper was granted by permission of the
Association for Computing Machinery. [Omitted in republished version
of RFC333.]
N.B. The ideas of section 4 of the following paper are in no way
critical to the ideas developed in section 3--DCW.
[ This RFCwas put into machine readable form for entry ]
[ into the online RFCarchives by Via Genie 3/00 ]