Re: A proposal for a General Clustering Framework

[Alan Robertson <alanr@unix.sh>]

Bill Todd wrote:
> 
> As the newest of newbies (having joined my first Linux list today), I'm a
> bit hesitant to voice too strong an opinion yet.  But I will suggest that at
> least some LAN-resident cluster implementations might prefer a base
> communication mechanism allowing lighter-weight (one-way) datagrams rather
> than requiring RPC-style responses for *all* messages:  message loss in (at
> least switched) LANs can often be made sufficiently rare that the mechanisms
> one needs anyway to allow for node failure can handle message loss as well,
> making responses superfluous in the many cases that don't fit the
> request/response paradigm (there are quite a few, for example, in the
> implementation of distributed file systems and caches).

Message loss is no problem to this layer of the system.  The underlying
infrastructure must retransmit, etc, so that's not an issue.  As an example,
you can see how heartbeat does this by looking here:
	http://linux-ha.org/comm/

I really think that RPC is more often not what you want.  I didn't mention
RPC, but others did.

In a cluster, there is often event notification (which is not
bidirectional), and often other kinds of multicast operations.  RPC is
neither necessary nor sufficient for cluster communications.  People use
barriers, semaphores, transactions, etc as suitable models.  I don't see RPC
as the right paradigm.  On the other hand, a cluster-aware can use RPC to
communicate with a *local* daemon to get barrier, membership, transaction
services, etc from a local process...  But across the cluster, I don't think
it's that suitable.

The typical paradigm for a cluster communication doesn't look at all like
normal client-server interactions...

	-- Alan Robertson
	   alanr@unix.sh

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