Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!krowitz@EDDIE.MIT.EDU@mit-kermit.UUCP
From: krowitz@EDDIE.MIT.EDU@mit-kermit.UUCP
Newsgroups: mod.computers.apollo
Subject: Re:  IPC
Message-ID: <8701210919.AA05252@EDDIE.MIT.EDU>
Date: Wed, 21-Jan-87 00:06:16 EST
Article-I.D.: EDDIE.8701210919.AA05252
Posted: Wed Jan 21 00:06:16 1987
Date-Received: Wed, 21-Jan-87 19:37:16 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 20
Approved: apollo@yale-comix.arpa

Actually, I suspect there are more than a few of us end-users who
would like to use the IPC calls rather than the MBX calls because of
1) the speed of the IPC calls vs MBX, and 2) the fact that a program
using the IPC calls does not have to depend on another process 
existing and being healthy. As you point out, however, IPC calls
are an unreliable way of sending packets; and it takes a fair amount
of programming to build a useful packet sending package on top of
the IPC mechanism. The TCP calls are documented in the system call
reference manual or in the interprocess communication manual where
the average AEGIS system programmer who expect to find them. A fast,
reliable, packet sending package would be a real help for things
like a multi-user flight simulator. MBX is just too slow for
things which require more than a couple of updates a second, and
there have been too many times when the TCP server has died, hung,
or lost a routing table to make me want to depend on it. I think
the person who originally had the IPC question was trying to
build a reliable packet service on top of IPC for this very
reason.

					-- David Krowitz