Use of IPC Facilities: A Working Paper
RFC - Unknown
(May 1971; No errata)
||RFC Editor Note
RFC 150 (Unknown)
||Send notices to
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
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 be made here to design
suitable solutions to the problems raised. To be useful, such solutions
must be machine dependent. A so called 'general solution' would actually
be too clumsy and inefficient to be of any value. Secondly, we take the
point of view of the user, who need not be aware of the manner in which
his demands are carried out, so long as they can be accomplished.
Finally, we are trying to stay aloof from the eccentricities of present
day machine organization.
In our attempt to be implementation independent, we are admittedly
treading a fuzzy line. Our characterization of usage patterns presumes
both a system/process software organization and a computing milieu
capable of supporting it. Although this does not appear to significantly
affect the generality of the document, some care must be exercised in
the selection of host machines.
In the rest of this paper, we attempt to characterize the types of
usage that should be anticipated by an IPC facility. The organization is
into titled sections, each section discussing some aspect of the
ABILITY TO USE VARIOUS SOURCES OF WAKEUP INFORMATION
Most processes exhibit preferences toward certain quantities of
input data. This preference is reflected in the amount of computing time
that can be expended for a given amount of input. For example, a
character translation routine might prefer eight bit quantities of
input. With seven or less bits no processing is possible, but once a
complete character is available an entire translation cycle can
commence. This preference is independent of the function of the routine.
Otherwise equivalent routines could be written that would accept one bit
at a time. In other examples, a command interpreter might require a
Show full document text