Xref: utzoo comp.unix.questions:4974 comp.unix.wizards:6008 comp.sys.apollo:603
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!zen!ucbcad!ames!necntc!dandelion!ulowell!apollo!mishkin
From: mishkin@apollo.uucp (Nathaniel Mishkin)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.sys.apollo
Subject: Re: Interprocess Communication
Keywords: shared memory, mailbox, sockets, TCP/IP, XNS, heterogeneous networks.
Message-ID: <39886200.c366@apollo.uucp>
Date: 7 Jan 88 14:35:00 GMT
References: <7808@eddie.MIT.EDU> <2958@super.upenn.edu>
Reply-To: mishkin@shrew.UUCP (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 72

In article <2958@super.upenn.edu> george@apollo.lap.upenn.edu (George Zipperlen) writes:
>In article <7808@eddie.MIT.EDU> you write:
>> 	1). The shared memory facility allows two processes to
>> 	communicate through a common chunk of memory, and support is
>> provided for mutual-exclusion locking allowing one to implement a
>> samaphore abstraction.  This method does not work across a network,
>> only within a single node.
>I see several problems with shared memory in a network.
>Which node's memory is being mapped?  If more than one, how do you 
>synchronize all changes?  I think that what you would need for this
>is remote procedure call.  My limited knowledge of Apollo's NCS 
>(Network Computing System) is insufficient to answer these questions.

Shared (virtual) memory -based IPC is, in general the fastest way to
go.  However, it depends on all the processes that are communicating
via IPC sharing a common physical memory.  The sharing is implemented
via the memory management hardware -- virtual pages in multiple processes
are mapped to the same physical memory pages.  (I.e. we don't pretend
to *try* to hack the synchonization problem.) Thus, VM-based IPC can
be used only when all processes that are communicating are running through
the same physical memory.

>> 	2). Aegis provides a socket abstraction, similar in spirit (I
>> 	think -- never played with it) to the standard Unix socket
>> abstraction. Again, this does not work between nodes, although I can
>> see no reason why this restriction exists (can anyone shed some light
>> on this point).
>
>    To use sockets between nodes (or over the ethernet to other systems)
>you need the TCP/IP server. This in fact works very well. For example: 
>telnet, ftp, X-windows... (This one I know fairly well (:-) )

In fact, the socket abstraction can in principle be used over a variety
of "protocol families" (e.g. IP, XNS).  Currently, the only protocol
family Apollo supports is IP.  However, the good news is that on Apollos,
anyone can add support for a new protocol family withOUT having to rebuild
the kernel.  (Well, you need one more include file that I'd happily donate
if someone really wanted to try to do this.)  This is done using Extensible
Streams (Open Systems Toolkit).  All you do is write a type manager that
supports the socket "trait" and then you can write programs that use
the regular BSD "socket", "send", "recv", etc. calls to talk over your
new kind of socket.

>> 	3). The third model is a server-client model. The actual
>> 	communication takes place through a *mailbox* file, located in
>> a particular place.
>
>I agree completely. The only addendum I would make is that mailboxes
>only work within the AEGIS domain, not in a heterogenous network.

Exactly.  This is one of the reasons we did NCS.  NCS is a remote procedure
call facility that is heterogeneous, not only in terms of what systems
(Unix, VMS, MS/DOS) it runs on, but also in terms of what protocol families
it runs over.

In addition to its being a good IPC mechanism because it supports
heterogeneity, NCS is good because RPC is often the most natural way
to do IPC.  Many IPC applications (especially those that are more oriented
to passing "control" and "query" information rather than doing bulk data
transfer) implemented using non-RPC techniques essentially end up doing
ad hoc RPC -- define a record, fill in values, send record over IPC
channel, wait for and receive reply with result record, extract values.
With NCS/RPC, you just define an interface with a set of procedures whose
parameters are the values you want to pass between processes.  To
communicate, you simply call the procedure defined in the interface.
(A special compiler turns the interface you wrote into a set of "stub"
procedures that do all the dirty work.)
-- 
                    -- Nat Mishkin
                       Apollo Computer Inc.
                       Chelmsford, MA
                       {decvax,mit-eddie,umix}!apollo!mishkin