Re: Re: Interdomain comms

[Eric Van Hensbergen <ericvh@gmail.com>]

On 5/6/05, Harry Butterworth <harry@hebutterworth.freeserve.co.uk> wrote:
> I skimmed what I could find immediately on 9P:
> http://www.cs.bell-labs.com/sys/man/5/INDEX.html and came to the
> conclusion that what I proposed is lower level and more general (it's
> also simpler but, given that it's not doing the same thing, that isn't
> really significant).

There isn't a great deal of detail on the specifics of the protocol
beyond the man pages.  I think you'll find the following Plan 9
foundational papers more illustrative of the type of things that it
can be used to do:
        http://plan9.bell-labs.com/sys/doc/9.pdf
        http://plan9.bell-labs.com/sys/doc/names.pdf
and in particular:
        http://plan9.bell-labs.com/sys/doc/net/net.pdf
For the security minded:
        http://plan9.bell-labs.com/sys/doc/auth.pdf

I believe Ron's original statements were motivated by your earlier statement:
>>
>>The event-channel and shared memory page are fine as low-level
>>primitives to implement a comms channel between domains on the same
>>physical machine. The problem is that the primitives are unnecessarily
>>low-level from the client's perspective and result in too much
>>per-client code.
>>

This is exactly the sort of thing that the Plan 9 networking model was
designed to do.
The idea being that the Plan 9 model provides a nice abstract layer
which to communicate with AND to organize (the organization is an
important feature) the resulting communication channels and endpoints
(no matter what the underlying transport is or where the particular
endpoints may be).  The Plan 9 networking model can be run over named
pipes, shared memory, PCI buses, Ethernet, Infiniband, or whatever
other flavor of network with relatively minor requirements on the
underlying transport layer.

> 
> You could implement 9P on top of my IDC API proposal
>

You could implement 9P on top of such an IDC API, however, it seems
like it would add unnecessary overhead.  9P can be easily implemented
directly on top of the existing event/shared-page mechanisms and then
trivially bridged to the network at the I/O partition(s).  As far as
multi-level protocol stacks and circumventing data paths, I'd hope we
could come up with a simpler, more elegant solution.

Looking over your earlier proposal it seems like an awful lot of
complexity to accomplish a relatively simple task.  Perhaps the
refined API will demonstrate that simplicity better? I'd be really
interested in the security details of your model as well when you
finish the more detailed proposal.

>>
>>The inter-domain communication API should preserve the efficiency of
>>these primitives but provide a higher level API which is more convenient
>>to use.
>>

I think this is a great mission statement -- convenience and
simplicity are the key to selling such an API.

I'd suggest we step through a complete example with actual
applications and actual devices that would demonstrate the problem
that we are trying to solve.  Perhaps Ron and I can pull together an
alternate proposal based on such a concrete example.

           -eric