Marcel Ruff ([EMAIL PROTECTED]): > > 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
