On 17 October 2007 at 2:20 PM, Tomasz Sterna wrote: > Dnia 17-10-2007, Sr o godzinie 13:52 -0700, Mark Doliner pisze: > > > When the router detects bind conflict. It tells the conflicting > > > components to "go to the lower level". > > > > And there would be a bind conflict when two sm instances try to > > connect to router with the id "jabber.org," right? > > And it would also happen when a single user logs in from two > > locations using two different resources? > > Exactly. > I've described it in "Another step:" part of the example. > > > > > > how does c2s decide which sm instance to forward the login to? > > > > > > C2S needs changes in the SM tracking logic. > > > When it receives advertisements of bare-jids, it starts routing by > > > bare-jids, not domain. Same for full-jids. > > > > When a user logs in they get assigned to one of the sm instances, right? > > Right. > The SM that responded to the session creation request. > We need to record it in the SM. :-) > > (Yes, we do crystallize the idea now. :-) ) > > > > How would c2s decide which sm instance they should be assigned to? > > Would the router make that decision somehow? > > Yes. It's router to decide which instance receives the packet addressed > to the SM (domain) itself. Round-robin comes to mind. Or we could count > sessions hanging on the SM and pick the less busy one. > > Using the routing trees (last paragraph) it's trivial to get needed > information.
I've uploaded an initial patch for this to http://jabberd2.xiaoka.com/ticket/170 . It's not finished, but I am at least able to have two sm instances connect to one router, and have two clients log in and exchange messages. I wrote a more detailed description in the ticket. -Mark
_______________________________________________ Jabberd2 mailing list [email protected] http://lists.xiaoka.com/listinfo.cgi/jabberd2-xiaoka.com
