Re: A proposal for a General Clustering Framework

[Alan Robertson <alanr@unix.sh>]

Michael E Brown wrote:
> 
> On Tue, 5 Jun 2001, Alan Robertson wrote:
> 
> >
> > Clearly whatever we do will BY DEFINITION be a significant extension over
> > the XML-RPC spec.
> >
> > 1) we won't support HTTP
> > 2) we will allow calls without explicit replies (event notification)
> > 3) we need to indicate which domain the message is within.  By that I mean
> >       which application program on the destination end will receive the
> >       call...
> 
> Alan,
> This is what I was talking about in my last message about
> transport-independence. I know SOAP has a clearly defined spec for it, I'm
> not sure about XMLRPC. Clearly, SOAP is too heavyweight for our task, so I
> would propose 'backporting' the transport-independence into the XMLRPC
> protocol.
> 
> So, to answer your points line-by-line...
> 
> 1) We simply define a new 'lightweight' transport.

The transport in the architecture heartbeat implements provides for multiple
"pluggable" transports.  The framework will do the same.  So, we don't
define a single transport, but a transport API, and leave the rest to the
plugins.

> 2) Already supported. (or do you mean a UDP-like 'unreliable' transport
> mechanism?)

Neither.  I mean a sender-API difference.  On the wire there's no
difference.  But, in the requestor, the API code needs to know not to wait
for a reply.

> 3) Trivially done within XMLRPC. You can do either of two ways: 1) have an
> XMLRPC 'listener' for each application, or define part of the api that
> specifies which app a message will go to.

This is clearly allowed for by the spec (see my previous email).

> >
> > I also thought of a third extension:
> >
> > 3) Allow calls to multiple nodes in the cluster.  There would be another
> > parameter for the list of machines in the cluster to be called, and one for
> > a timeout value.  The caller would be notified once all the replies came in,
> > or timeouts had occurred, or (optionally) cluster membership had changed...
> >
> 
> The above will be taken care of with a 'multicast' transport. The message
> payload will be the same as a normal XMLRPC message, it will just be
> multicast to a list of cluster members.

On the wire, the payload's the same, but in the API, there's a huge
difference in what has to happen...  In my view, the application shouldn't
specify transport, so from the point of view of the application, it's not a
multicast transport, but simply a list of destinations.  The transport layer
needs to make them show up at their destinations somehow.  It might ALL be
through serial links if that's how you have it configured underneath.  But,
this is not the applications's concern.

The conclusions I would draw are these:

	The XML-RPC payload is OK as is (but be careful about positional
		parameters - one parameter is best)

	The data on the wire will probably not match the XML-RPC spec's idea of
		what it should be. (different "envelope").

	The API interface code will also have to be different.

So, we've saved (kept) the parsing, but everything else is broken from the
point of view of perfection.

This is not intended as a complaint, but as a statement of fact as best I
understand it.

	-- Alan Robertson
	   alanr@unix.sh

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