Browse Prior Art Database

Use of IPC Facilities: A Working Paper (RFC0150)

IP.com Disclosure Number: IPCOM000002328D
Original Publication Date: 1971-May-05
Included in the Prior Art Database: 2000-Sep-12
Document File: 9 page(s) / 26K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.B. Kalin: AUTHOR

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 10% of the total text.

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.

INTRODUCTION

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.

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