Xref: utzoo comp.unix.questions:4964 comp.unix.wizards:5993 comp.sys.apollo:602
Path: utzoo!utgpu!water!watmath!clyde!rutgers!super.upenn.edu!hyper.lap.upenn.edu!george
From: george@hyper.lap.upenn.edu (George Zipperlen)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.sys.apollo
Subject: Re: Interprocess Communication
Summary: TCP/IP sockets work on Apollos
Keywords: shared memory, mailbox, sockets, TCP/IP, XNS, heterogeneous networks.
Message-ID: <2958@super.upenn.edu>
Date: 6 Jan 88 21:20:58 GMT
References: <7808@eddie.MIT.EDU>
Sender: news@super.upenn.edu
Reply-To: george@apollo.lap.upenn.edu (George Zipperlen)
Organization: University of Pennsylvania, Language Analysis Project
Lines: 73


I was going to respond by e-mail, so as not to expose my ignorance to 
whole net, but decided that others might be interested in my ramblings,
since a previous news message inquired about heterogenous networks. 

A few words about our configuration: 
we currently have our Apollo ring running Aegis and Domain/IX (bsd4.2 TCP) 
connected to a local ethernet.  Also on the local net we have a Gould 
powernode (UTX - bsd4.2 with some sys5 features); and a Xerox dandelion 
(XDE, ViewPoint).  The local net is connected to the Penn-Net, which links 
us to the Arpa Internet (shin bone connected to the thigh bone (-:).  
We've got the Gould talking tcp, and we're currently trying to talk to 
the dandelion. (Credit here should mostly go to my co-worker, Adam Feigin).
Another possibility is to get XNS running on the Gould.
We also have PC/ATs (UGH) connected by DPCI over serial lines, and 
Macintoshes running MacApollo.

Disclaimer: I am mainly familiar with mailboxes and sockets, and am 
theorizing about shared memory.

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. It is thus useless for implementing truly
> parallel systems on an Apollo ring, but seems to me that it is the
> fastest -- requires the least amount of system overhead.

    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.

> 	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 (:-) )

> 	3). The third model is a server-client model. The actual
> 	communication takes place through a *mailbox* file, located in
> a particular place. This abstraction works across nodes.  It assumes
> the existance of a filesystem which allows transparent internode file
> access (such as the Aegis file system).  Seems to me to be the simplest
> to use, and since it works across the net, allows the implementation of
> truly parallel applications. It also seems to be the slowest, requiring
> the most amount of system overhead of all three methods I've
> mentioned.

I agree completely. The only addendum I would make is that mailboxes
only work within the AEGIS domain, not in a heterogenous network.
Back to theorizing mode: I think you could write code for extended
mailboxes using the open systems toolkit. This is something we may
need to do to communicate with XNS systems - possibly easier than
trying to get a TCP server going on the other end.

> 						-- Rich (rich@eddie.mit.edu).
> 	The circle is open, but unbroken.
> 	Merry meet, merry part,
> 	and merry meet again.

--------------------------------------------------------------------------------
George Zipperlen                    george@apollo.lap.upenn.edu
Language Analysis Project           (215)-898-1954
University of Pennsylvania          Generic Disclaimer
Philadelphia, Pa. 19103             Cute saying
--------------------------------------------------------------------------------