Re: understanding 9grid and clustering?

of course, <thread.h> only works on a single machine, and indeed
within a single shared memory space.  applications using the send/receive
messaging primitives of thread(2) are also typically written in a way
that suggests that if the primitives were to fail, it can be regarded
as fatal (no memory, little chance of recovery, and similar).  they
are sharing an address space too, so `authentication' isn't done.

by contrast, when crossing network boundaries
(whether inside a larger box or not) failure is possible, often moderately
probable, authentication is necessary in general, and thus
a different communication model is used.  it would be possible
to implement a group messaging model including exceptional returns
on error, but plan 9's usual approach to distribution is a little different.

normally when considering a distributed application with plan 9,
i'd think whether i could sensibly have one or more nodes serve
a name space, representing the resources i wish to distribute.
the name space would typically be implemented using 9p(2).
it can then be securely exported and imported across nodes.
access to those resources is then by normal open/read/write
calls.  what those requests actually do is up to your 9p server.
it's convenient to have names for resources (rather than numbered ports say),
and having a related group of names collected into a name space does give
some structure to the whole.  it provides obvious ways to locate
things or enumerate them, for instance.  read and write operations
already allow for failure and applications invariably check
the result of those calls most carefully.  of course, it's perfectly
possible to build a group communication system or
atomic actions under a name space.

the use of a name space for one function doesn't prevent use of other
mechanisms.  for example, in a game-playing system, we used a name space to provide
the `lobby' in which players meet and find games to play, and had
one of the files associated with a game contain a network address
for a datagram service, partly to allow it to work with existing games.
(isochronous support in 9p wouldn't have helped there, because
games expected UDP or perhaps RTP, but might be useful elsewhere.
i thought it might be easy to do, but it hasn't been mentioned for years.)

there are many more possibilities.   the use of a name space
to structure an application is not limited to ones that are physically
distributed; acme(4) provides a good example.  of course, having
structured something that way might make it easier to distribute
its functions.

for applications spanning several nodes, of course
at a basic level there is also dial(2), which is a little easier to use and
more general than sockets but no more helpful.

`computable name spaces' is plan 9's higher-level abstraction
for distribution.  i say `higher-level' when compared to the usual RPC-based
schemes such as RMI or SOAP and Web Services, or even group communication
systems in the right applications.  it also makes it fairly easy to organise basic cross-node
workflow using pipelines and shell scripts.
one big difference in the underlying implementations is that the
code required for 9P is tiny by comparison, and there isn't the usual
geological layering of software before anything gets done.

one current pitfall is perhaps suggested by aan(8).  it's one thing
to detect an error on read or write, another to recover from it.
still, even there a name space implemented locally can hide many
recoverable errors from an application sitting above it,
shifting requests from a failed service to another.
in any case, a resilient distributed system must
be designed as such; name spaces might or might not make
the design step easier but the underlying implementation still
needs to be able to do the traditional things for recovery.