Use of IPC Facilities: A Working Paper (RFC0150)
Original Publication Date: 1971-May-01
Included in the Prior Art Database: 2019-Feb-10
Internet Society Requests For Comment (RFCs)
Richard Bl. Kalin Network Working Group MIT Lincoln Laboratory Request for Comments #150 5 May 1971 NIC 6754
THE USE OF IPC FACILITIES
***A WORKING PAPER***
This material has not been reviewed for public release and is intended only for use within the ARPA network. It should not be quoted or cited in any publication not related to the ARPA network.
It is our hypothesis that the goals of interprocess communication are more complex than commonly realized, and that until this complexity is more fully understood, there will be no satisfactory implementations. The objective of an IPC design must be more than that of providing a facility for moving bits between otherwise independent user programs, a variety of other constraints must also be satisfied.
These constraints are dictated by the eventual usage of the facility. Any design that will sustain this usage pattern can be a satisfactory one. If it does so efficiently, it will be said to be well designed. Furthermore, it is unimaginable that a large design effort, undertaken without a complete understanding of the usage it must serve, will ever be well designed or even satisfactorily designed.
This paper undertakes the exposition of the types of usage to which an IPC facility would be subjected, in hopes that such a discussion will clarify the goals being pursued and will provide a benchmark for gauging various implementation strategies. The difficulty of this task should not be underestimated. The only experience available for us to draw upon is from very primitive and overly constrained IPC implementations. Extrapolation from this limited usage environment to more general notions has as yet no basis in real experience. Such speculation is therefore subject to enormous oversight and misguided perspective.
In compiling this paper, it was necessary to imagine what services a process might want from an IPC facility. The areas recognized include: 1) the exchange of bit encoded information via channels. 2) the establishment, deletion, and reassignment of these channels. 3) the ability to debug errors and suspected errors. 4) the potential to improve running efficiency. 5) the capacity to avoid storage allocation deadlocks. 6) the aided recovery from transmission errors.
RFC #150 Use of IPC Facilities 5 May 1971
This list is known to be incomplete. Some areas, such as understood to be intelligently discussed. In other cases, omissions should be blamed on simple oversight.
Because of these obvious problems, one should not consider any document of this kind as either authoritative or final. For this reason, this paper is being kept as a computer based textfile, and so will remain subject to editting and rerelease whenever new insights become understood. We hope that it can remain an accurate and up to date statement of the goals to which any group of IPC implementers can aspire and, as such, can be a guidebook to the problems that must be faced.
For several reasons no attempt shall...