haitex@pnet01.cts.com (Wade Bickel) (04/07/88)
The IPC (Inter-Process-Communications) Discussion still rambles forth
without focus...
... so I guess I'll add my two bits :^).
I suggest that IPC consist of a mechanism for registering and
lauching tasks, and manageing shared memory and code. Leave the details
beyond this to the programmers who need the facility. Standards for
things such as file transfer formats can be hashed out later by those
who have need for them.
Basically, I envision the mechanism as one which handles the
following:
1) Registration of New IPC recognized tasks. On startup
a user program needs to go through a registration
process to establish communications with IPC.
2) Allocation/Deallocation of Memory in response to
registered client programs. This space would be
available for any use, but the facillity is
needed for shared memory handling.
3) Handling of a shared code facility.
4) creation of connected message ports for client tasks.
5) It might be desireable to have process which spawn
sub-tasks to be able to do so as a request to
IPC.
In this way the coding of the IPC mechanism can be kept to a
reasonable level and no limitations will be imposed. The biggest
hurdle would creating an expanded message port handler to allow
larger numbers of message ports.
Thanks,
Wade.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COMkgschlueter@orchid.waterloo.edu (Kevin Schlueter) (04/12/88)
Just a quick note about this IPC discussion. Has anyone read about the V kernel, being developed at Stanford by Cheriton et al? Basically, the project involves setting up a distributed system consisting of Sun workstations (at least that's what they were using in the article I read -- there was some mention of including VAXES). It would seem that we could at least borrow the primitives from the V kernel. Perhaps we might want to borrow the server philosophy as well. In any case, I think that we could avoid alot of mistakes by reading about it.
root@sbcs.sunysb.edu (SBCS Systems Staff) (04/13/88)
In article <12379@orchid.waterloo.edu>, kgschlueter@orchid.waterloo.edu (Kevin Schlueter) writes: > Just a quick note about this IPC discussion. Has anyone read about > the V kernel, being developed at Stanford by Cheriton et al? Basically, Yes! Would've been a nice starting point for AmigaDOS.. > the project involves setting up a distributed system consisting of Sun > workstations (at least that's what they were using in the article I read -- > there was some mention of including VAXES). It would seem that we could > at least borrow the primitives from the V kernel. Perhaps we might > want to borrow the server philosophy as well. In any case, I think > that we could avoid alot of mistakes by reading about it. And you probably would want to import Cheritons new VMTP network protocol too. At least that's what I going to do in the next release of Ameristar's network code. Nice thing about VMTP is that it is a freebie from Stanford. Rick Spanbauer SUNY/Stony Brook
peter@sugar.UUCP (Peter da Silva) (04/14/88)
In article ... kgschlueter@orchid.waterloo.edu (Kevin Schlueter) writes: > there was some mention of including VAXES). It would seem that we could > at least borrow the primitives from the V kernel. Perhaps we might We have the primitives. What we are (or should be) discussing is the message formats and how the programs hook up in the first place. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
kgschlueter@orchid.waterloo.edu (Kevin Schlueter) (04/16/88)
But do we really have the primitives? If you're thinking of using EXEC, how
are you going to extend it to work across multiple machines (yes, I know you
could patch it, however that's messy). We should come up with a new set of
primitives to be used in communicating between foreign programs (ie IPC within
processes all belonging to a single program could still use EXEC) that will
make communications between processes on different machines completely
transparent. It is in that spirit that I suggested looking at the V-Kernel.
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.
We shouldn't reinvent the wheel if we don't have to. Let's make use of existing
distributed systems research if it is appropriate.
I really think that we need to define the primitives more than the protocols.
I really think that it's hopeless to try to define alot of protocols. Let
the interested (and knowledgeable) groups get together to define specific
protocols, it's our job to give them something versatile and extensible
to do it with (this is alot like the philosophy behind IFF).
I think what we really need is this:
1. Some way of identifying servers and the service they provide (ie nameserver
or whatever).
2. Some low level method of transferring data between client and server (ie
our primitives). This method must allow for client and server to be on
different machines.
The V-kernel addresses these issues. I don't have the pertinent paper with me
right now, but I believe it was in IEEE Software, April 1984. We should all
read this paper.root@sbcs.sunysb.edu (SBCS Systems Staff) (04/16/88)
In article <12388@orchid.waterloo.edu>, kgschlueter@orchid.waterloo.edu (Kevin Schlueter) writes: > > The V-kernel addresses these issues. I don't have the pertinent paper with me > right now, but I believe it was in IEEE Software, April 1984. We should all > read this paper. Let me go a bit further and suggest that everyone involved in the IPC thing go out and read all of the Cheriton/Zwaenepoel papers on the V kernel and the work that lead up to it. Also suggested reading is the paper on the Ridge message passing kernel. You might also do well to read the Cambridge Ring book. After you're basically sold on message passing as IPC, read the recent Bill Joy interview in Unix Review (?). Here are some references to get started: (1) Cheriton, etal, "Thoth, a portable realtime operating system". Comm ACM 22, Feb 1979. PS. Cheriton was at Waterloo when he wrote this paper. Perhaps this accounts for the original authors interest in V :-) ? (2) Needham & Herbert, _The Cambridge Distributed Computing System_, Addison-Wesley, Reading, Mass., 1982. (3) Cheriton & Mann, "Uniform Access to Distributed Name Interpretation in the V-System", some IEEE conf 1984. (4) Basart, E, "The Ridge Operating System: High Performance Through Message-Passing and Virtual Memory", some IEEE conf 1985. (5) Cheriton & Zwaenepoel, "The Distributed V Kernel and Its Performance for Diskless Workstations". Proceedings of the Ninth ACM Symposium on Operating System Principles, Oct 1983. Sorry about the vague publication credit in (3) & (4). I'll dig up the proceedings if interest merits it. Another nice reference is to get a copy of the V System manual from Stanford. Anyways once you've traced the literature tree from the above references, be sure to look at: (6) Cheriton, "VMTP: Versatile Message Transaction Protocol Protocol Specification", Internet RFC1045. If you need some convincing to go out and read the literature, be sure to look at the performance figures given in (4). Just think of what we could do with the Amiga if we transplanted the V I/O system onto the Amiga..... As for Ameristar, we are looking at including (6) in one of our next releases. The application interface will probably be sockets at first, and perhaps the "Usenet standard" if one can be agreed upon. Rick Spanbauer SUNY/Stony Brook (& Ameristar)
pete@violet.berkeley.edu (Pete Goodeve) (04/23/88)
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.