Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!agate!violet.berkeley.edu!pete From: pete@violet.berkeley.edu (Pete Goodeve) Newsgroups: comp.sys.amiga Subject: Re: An alternative IPC system Message-ID: <9132@agate.BERKELEY.EDU> Date: 23 Apr 88 08:33:17 GMT References: <2783@crash.cts.com> <12379@orchid.waterloo.edu> <1833@sugar.UUCP> <12388@orchid.waterloo.edu> Sender: usenet@agate.BERKELEY.EDU Reply-To: pete@violet.berkeley.edu.UUCP (Pete Goodeve) Organization: University of California, Berkeley Lines: 97 There have been a couple of postings recently advocating Cheriton et al's "V kernel" as a basis for our IPC standard <12379@orchid.waterloo.edu> <1135@sbcs.sunysb.edu> <12388@orchid.waterloo.edu>. Sorry folks, but I think that this is a major red-herring. Just to make sure, though, I did go back and re-read the April '84 article in IEEE Software. Much as I admire the "V" system, its origin and rationale are quite different from the environment that we expect to be working in, so the protocols and primitives it uses aren't appropriate for us. A distributed environment has very different constraints from the multi-process/common- memory box we have in front of us now. I'm NOT saying we shouldn't look forward to multiprocessor (like Transputer?!) distributed systems, but we mustn't hamstring local processes by insisting that they obey all the restrictions of that environment. In fact the Port/Message environment built into the Exec is already far more suitable. We can address messages to ports rather than to processes (as V does) and we can use meaningful strings, rather than 32-bit IDs, to locate the address (though after that of course we use 32-bit IDs too -- they're called "addresses"). Where we really part company with V, though, is in our approach to accessing data. In a distributed system, you usually don't have direct access to a block of data at a remote site, so V's message protocol is based on COPYING. Further, copying can only happen during "rendezvous" (to borrow a term from a DoDdery language) -- i.e. while the sender is SUSPENDED. If you've been following the discussion on the net, though, you'll realize that one of our main concerns has been speed: it is much better to pass the receiver process a pointer to the data (and permission to play with it) than to copy large blocks; saves memory too -- especially when you're passing bit maps around. Yes, I know that we then hit the old problem of collisions, where both client and server want to get at the data at the same time, but this is what the ReplyMsg mechanism is for. The server doesn't reply until it has finished with the data block; the client knows not to mess with it until it receives the reply, but meanwhile it can get on with other things -- it need NOT be suspended. Past articles in this discussion have dealt at fair length with the different constraints on local and network message passing. There are lots of things that are reasonable to pass to a local process, but that make no sense over a network -- things like port addresses, file locks, and file handles. And think of a linked list: locally, all you have to do is pass a pointer to the head, but for shipping out on a net you have to disassemble it, send it item by item, and reassemble it (with local pointers) at the other end. In article <12388@orchid.waterloo.edu> Kevin Schlueter writes: > But do we really have the primitives? [....] ^^ Yes, I think we do, at least in reasonable outline. > It is interesting to note that the V-kernel already deals with the issue > of broadcasting messages (ie 1 to many service), which I noticed someone > just raised. Umm.. "Just raised"? This was one of my very first suggestions when this discussion started -- about two months back. And yes, I believe the V kernel was one of the dim original stimuli to this thought. > We shouldn't reinvent the wheel if we don't have to. [.....] Yes, but you don't want to put a tractor wheel on a bike... > I think what we really need is this: > > 1. Some way of identifying servers and the service they provide (ie nameserver > or whatever). I think named ports do this very well. At a higher level, for more detailed identification of services, we may well end up with some sort of "method/object" scheme. (Though I definitely think of our IPCMessage format and so on as being at the kernel "level" -- management protocols such as method/object should go ont TOP of whatever lowest level protocol we decide on. The reason is to avoid stifling alternative proposals at this stage -- they should ALL have a chance to be tried out.) > 2. Some low level method of transferring data between client and server (ie ...IPCMessages... > our primitives). This method must allow for client and server to be on > different machines. See the discussion above. I suspect a "distributed IPC kernel" on the Amiga will take the form of a local server that knows how to make messages suitable for net transmission, and complains if it can't. Our IPCMessage format is designed to make this possible even though the server doesn't know the nature of the message data. _______________________________________________________________________ -- Pete -- BTW -- Can we now move this discussion over to comp.sys.amiga.tech, please? ...At least when we start any new threads.