The IQ application will be briefly unavailable on Sunday, March 31st, starting at 10:00am ET. Access will be restored as quickly as possible.
Browse Prior Art Database

Use of IPC Facilities: A Working Paper (RFC0150)

IP.com Disclosure Number: IPCOM000002328D
Original Publication Date: 1971-May-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 12 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.B. Kalin: AUTHOR

Related Documents

10.17487/RFC0150: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 12% of the total text.

Richard Bl. Kalin Network Working Group MIT Lincoln Laboratory Request for Comments #150 5 May 1971 NIC 6754



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.

[Page 1]

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...