Re: A proposal for a General Clustering Framework

[Greg Lindahl <lindahl@conservativecomputer.com>]

On Tue, Jun 05, 2001 at 05:21:02PM -0400, Jeff Darcy wrote:

> They're different because RPC, by definition, involves a reply to indicate
> completion (and possibly a result).  Bear in mind that RPC is a general and
> often-abused term; there are many kinds of RPC, and some RPC packages
> contain non-RPC functionality.

I suspect most people here are using the non-RPC form of RPC, which
would explain why they went "Huh?" to your note. And that's why
there's more heat than light happening.

> They come into play in several ways.  Every protocol that one might use -
> e.g. for membership or consensus - has a very particular set of requirements
> regarding message reliability, ordering, etc.

That's correct. And if you make these requirements explicit and
available to the lower layers, they can provide appropriate
services. The usual problem is that these requirements aren't written
down anywhere or are simply not known by the programmer.

> What's less obvious is that
> *exceeding* the protocol's requirements can be just as dangerous.  For
> example, a protocol might be able to tolerate a certain amount of message
> loss, but not duplication.  Add retransmission and you add a potential for
> duplication, and you might well break your consensus protocol.

This is an odd example. The requirement of "no duplicates" was simply
not specified. I wouldn't calling that "exceeding the protocol's
requirements". Perhaps a better example is an application which does
not require ordered delivery using a protocol which only provides
ordered delivery. The application may see significantly higher
latency when a message is lost.

Legion (a distributed system whose lowest layer is dataflow)
introduced a taxonomy of requirements, but it could be that there are
other existing taxonomies. I'm not up on the literature.

> The SPOF is not in the RPC itself, but in the topology that RPC -
> indirectly - forces upon the system.  What I was thinking of, specifically,
> is the SPOF represented by the hub in a star topology.

And that depends on what your definition of RPC is.

> The
> essence of the problem is that the best-known and most reliable algorithms
> for these tasks are based on pure messaging.  Adding RPC to this volatile
> mix doesn't really solve anything, and accomodating RPC's different
> "expectations" and behaviors just adds difficulty to an already-difficult
> problem set.

And that depends on what your definition of RPC is.

-- g

Linux-cluster: generic cluster infrastructure for Linux
Archive:       http://mail.nl.linux.org/linux-cluster/