Re: [xmlblaster] Updated cluster requirements

[Hugues Jerome <hugues at email.enst.fr>]

Marcel Ruff (ruff at swand.lake.de):

> > konichiwa minnasan, daijobu desu ka.
> 
> Michele, please translate.

I'll do it : Hello everyone, are you ok ?

> > but some other concepts are missing : how do I setup my node as a master,
> > do you want this caracteristic to be static or not ?
> see
> http://www.xmlblaster.org/xmlBlaster/doc/requirements/cluster.html
> (the example section at the very bottom).

I ve seen that, later in my mail I wrote that you may give some comment
on it since it was not clear from my point of view ...

> > case 1. and 3. are similar to some multicasting problems, this may
> > be a key to a solution
> 
> Could you explain further please?

first, I will state that P-t-P does not need clustering, just delivery
to one and only one another node, this may be straightforward to 
conceptualize, and separate from Pub/Sub (even if I do not know if 
P-t-P and Pub/Sub are separated in xmlBlaster)

so, clustering is required only for Pub/Sub.

my understanding of Pub/Sub is that it is a mechanism similar to
multicast : one app sends data to a virtual adress, this data is
received by multiple destinations. this virtual adress in multicast is
the topic in Pub/Sub.

if you look at you first diagramm (scalability), the problematic
is similar to the one that introduced multicast, instead of reaching
all the nodes with one source, you flood a tree. so each xmlblaster node
behaves as a multicast router. this problem is equivalent to the first
generation of multicast protocols (DVMRP and IGMP v1 or something like 
that) where there is one and only one localized source (the so-called 
master in your diagramm)

the third one (logical separation) is a bit more complex, since
there are multiple sources (each of your master behaves as a source,
responsible of flooding other nodes) I think this is adressed in 
IGMP v3, but I m not sure

no matter if these are the good protocols, my point is that since
there are some equivalences between multicast and pub/sub, you can
have a look to the RFCs to get some idea about the vocabulary in
use, the routing algorithms and see if they can help you

the topological structure of the tree in a multicast app is given
by the network structure, so this may not give you a good structure

An idea may be the following (totally not tested) :

* each node is given a priority, low priority means that the node
is close to the source (in terms of hop)

* each node is given a capacity, which determines how many nodes
it may serve as local master.

an algorithm may then be used to build the logical tree, given
these two parameters

exemple :

avalon, golan, frodo and bilbo do have priority equals to 1
heron has a capacity of 3

avalon, golan and frodo are served by heron
bilbo may not be served by heron, but can be served
by one of the 3 others, say bilbo, with a higher priority (now 2)

such an algorithm may help if you want to implement fail over 
and is also required dynamic link reconfiguration between nodes, 
which implies new problems ...

> thanks for your valuable feedback

you are welcome

regards

Jerome