mishkin@EDDIE.MIT.EDU@apollo.UUCP (Nathaniel Mishkin) (01/20/87)
I made an interprocess communications package using IPC calls. ...
First, you must know that that MBX package (or the portable TCP/IP "socket"
calls) let you do all this already.
Second, assuming there's some reason that you really want to use the
IPC calls, the correct solution to your problem is to have another process
that does nothing but listen for incoming messages and queue or deliver
(using files, or shared memory, or MBX, or sockets, or whatever) INTRA-node
to the process that actually wants the data.
Note also that the IPC calls are an unreliable datagram service. Packets
can be lost, duplicated, or received out of order. MBX and TCP-sockets
don't have these problems.
-- Nat Mishkin
Apollo Computer Inc.
Chelmsford, MA
{wanginst,yale,mit-eddie}!apollo!mishkin
-------krowitz@EDDIE.MIT.EDU@mit-kermit.UUCP (01/21/87)
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