Dnia 2012-09-18, wto o godzinie 21:50 +0200, Alexandre Jousset pisze: > About routing levels and the "user@domain" binding... With this > solution, there's no more domain-only level at the beginning, so each > SM should bind directly bare JIDs and domains (still with > auto-binding). > > Moreover, as the same SM will manage all "user@domain", there > is no more full JID binding level either... > > This simplifies binding and routing (and all changes needed to > the code), as we only have to maintain 2 hash tables (preferably), one > for domains (with multiple routes/priorities) and one for bare JIDs > (with only 1 route and no priority, everything would be managed by the > SM)...
Do we need priorities in case of domain binds? This would cause sm with higher priority to take all the load. Maybe weights instead priorities. This would help tune load balancing. > To sum it up, it is the end of the adaptive routing... And > this has an implication, it is that the router memory consumption will > be higher than before with single-router architecture... Then wouldn't > it be a good solution to --enable-multi-router at ./configure time? It > would add the burden of maintaining both binding/routing solutions > (hopefully only in the router) but it will make the changes invisible > to the currently deployed servers. Not really. You need bare-jid level binds only when there is more than one component handling the domain. If there is only one, you can do domain based routing without the need for user@domain binding. This approach does not use more memory than current solution. I won't accept #ifdef'd implementation. Even dynamic modules make releases difficult. Having switchable code is even more PITA. There were some screw ups with libsubst and mio implementations in the past. -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
