Hi again,
Le 29/08/2012 15:13, Tomasz Sterna a écrit :
Dnia 2012-08-29, śro o godzinie 08:08 +0200, Alexandre Jousset pisze:
I wondered if it was possible to run it in a cluster.
The answer is clearly "no", as far as I understood it.
[...]
I decided to think about what would be needed to "clusterize" jabberd2. The
result of my thoughts can be seen on a graph here:
http://dbx.gtmp.org/jabberd2-cluster.png
Clustering is a setup where several instances of the same object appear
and work like a single object, distributing the load.
jabberd2 is able to cluster c2s, s2s and recently sm components.
What you are reffering to is building a mesh of independent object
working cooperatively to perform a task.
You're right about the terminology. I was using the term "cluster" in
the sense of the whole functionality as seen by the users (and by other servers).
The problem with using JID hashing is that the number of components you
distribute load to has to be constant.
When you add/remove the component to the sm cluster you disturb (almost)
every sm connection.
In typical case when you have fixed number of sm instances handling a
domain it's acceptable, but in distributed, dynamic router mesh - it is
not.
Correct. When I took this decision it was to be able to have a "quick and
easy" way to do it. I was aware of the drawbacks. But I was also almost sure that
somebody from the project already had a better idea ;-)
[...]maintainers like me to give them the patches for review? As a pull request
on github?
For bugfixes do not hesitate to create pull-requests.
It's a good way of submitting code.
For review - just point us to a branch on github you committed proposed
code, and we'll review it. You can create pull-request later.
Ok for this.
--- 8< --- >8 ---
Now, for another mesh concept.
My idea is to implement it using dynamically adapting routing.
Currently router routes stuff based on domain only (ie. example.com).
This is good when only one component connection handles stuff for the
domain.
But what happens when there is more than one connection handling a
domain name? We need to somehow decide which connection should handle
the packet. Now we use a simple hack of deciding based on hash of JID.
This hack, and this is why I used the same, has the advantage of
requiring no memory nor network resources at all :-)
Consider the following scenario:
- we have a router up
[...]
- router pushes the packet to component1
How this works in a router mesh?
Simple:
- require unique component names
- share the routing tree
What do you think about this idea?
This is the way I should have done it ;-) But I wanted, as a start, do
it the way I did because of its (apparent) simplicity. And I didn't want to
create huge routing tables too. c2s and sm are quite big memory consumers when
many users are connected, I didn't want to make the router the same. But I'm
afraid this is unavoidable.
It should be easy to implement with minimum changes to router code, as a
lot of preparation was done during implementing current clustering.
Just replace the clustering tables, with trees, and implement the
dynamic routing adaptation.
Then the hard part - routing information sharing between interconnected
routers and conflict resolution. ;-)
I think that the conflict resolution (especially with more than 2
routers) is the real tricky part. I'll think about it.
As I'm not a lot used to the protocol(s), what kind of messages would
you see possible to share the routing information?
Some details about the tree structures would also be helpful.
--
-- \^/--
---/ O \-----
-- | |/ \| Alexandre (Midnite) Jousset | --
---|___|-----
