Dnia 17-10-2007, Śr o godzinie 10:34 -0700, Mark Doliner pisze: > I'm interested in adding clustering support to jabberd2.
Most of us are. :-) > We're noticing that sm is definitely a bottleneck in our jabberd2 > installation, Yes. SM is definitely a bottleneck for big deployments. I have an idea how to do it a flexible and efficient way. A way that would fix the SM problem too. I call it "dynamic routing tables". The idea is similar to the way TCP network handles the network segmentation. The router currently holds a list of connected components and its bound names. It uses this list to make a decision where to put a packet coming through. component port ------------------ c2s 11111 resolver 12222 example.com 13333 test.org 14444 test2.org 14444 So, when it handles packet destined to [EMAIL PROTECTED]/res it puts it to 13333 stream. (or falls back to defaultroute) One component is able to bind more than one name. But no more than one component can bind a name. Logically - router would not know where to put the packet in. We need to change the way, this bind conflict is handled. Instead of disallowing new bind of 'example.com' to a component, router would need to signal to the requesting component and component on port 13333, that they need to switch to bare-jid binding from domain binding. Then 13333 and 14444 would request binds of all it's bare jid's and the routing table would look: component port ----------------------- c2s 11111 resolver 12222 [EMAIL PROTECTED] 13333 [EMAIL PROTECTED] 13333 [EMAIL PROTECTED] 13333 test.org 14444 test2.org 14444 [EMAIL PROTECTED] 14444 [EMAIL PROTECTED] 14444 This way, router receiving packet for [EMAIL PROTECTED]/res would put it to 13333 stream and for [EMAIL PROTECTED]/home would go to 14444. Packets to SM itself would go to one of the shared routes - for load balancing. round-robin? Another step: component on port 13333 requests bind of [EMAIL PROTECTED] (user connected with another resource) generating conflict with component on port 14444. Router would then to signal to both components, that they need to switch to full-jid binding from bare-jid binding. After components bind all full JIDs the routing table would look like: component port ----------------------- c2s 11111 resolver 12222 [EMAIL PROTECTED]/cl 13333 [EMAIL PROTECTED]/res 13333 [EMAIL PROTECTED]/res 13333 [EMAIL PROTECTED]/res 13333 test.org 14444 test2.org 14444 [EMAIL PROTECTED]/home 14444 [EMAIL PROTECTED]/work 14444 And router can do a routing for [EMAIL PROTECTED]/res to 13333 stream. On this level we would need to track resource priorities too, but this is a minor. This dynamically expanding router tables would allow us to plug many SM processes handling same domain even on single host. That would distribute load to many OS processes. Balancer code could be reused to implement more than one default route S2S processes. Not only for incoming, but outgoing connections too. (When more than one component requests default bind.) Implementation note: This routing table would rather be a routing tree with domains on first level, bare-jids on the second and full jids on the third. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED] _______________________________________________ Jabberd2 mailing list [email protected] http://lists.xiaoka.com/listinfo.cgi/jabberd2-xiaoka.com
