Doesn't this make the router a bottleneck? Creating a clustering component as specified at http://jabberd2.xiaoka.com/wiki/Clustering appeals to me because it allows for multiple routers in addition to just multiple sm's.
It WOULD be nice to be able to take advantage of multiple processors in a single machine, though. Also, when would sm bind to a bare jid? Would it happen when the sm process is started? Or would it happen after the user authenticates? If it happens after authentication, how does c2s decide which sm instance to forward the login to? -Mark > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:jabberd2- > [EMAIL PROTECTED] On Behalf Of Tomasz Sterna > Sent: Wednesday, October 17, 2007 11:49 AM > To: jabberd2 development > Subject: Re: [jabberd2] Clustering > > 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 _______________________________________________ Jabberd2 mailing list [email protected] http://lists.xiaoka.com/listinfo.cgi/jabberd2-xiaoka.com
