Le 19/09/2012 00:19, Tomasz Sterna a écrit :
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.
I thought it was what you meant previously, sorry. But you're right, ok
for this.
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 was thinking about multiple SMs handling one domain. Maybe it would
be a good thing to say this (only 1 SM per domain to use less memory) in the
install / config guide after the changes.
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.
Ok again :-) Sorry for insisting ;-)
Now I have a question about the routers interconnections. In my proof
of concept, each router had IPs/ports of each other router (including itself,
just to copy/paste this part of the config file), and each one connected to
each other in a client-server way, trying to reconnect roughly each X seconds
(with a customizable X) in case of error / lost connection.
The "client" router component binded the domains it managed on the "server", so when the
server wanted to send a packet it used that bind information to route. Each router was at the same time a client and a
server, receiving packets from other routers on its "client side" and routing outgoing packets on its
"server-side".
This architecture is far from perfection of course, but it has the
advantage of being symmetric, avoiding problems about which router has to
connect to which router and some other issues.
How do you see these interconnections? How to configure them? What if
(and how) one add or remove a router/host from the cluster?
I'm thinking about something like editing the router.xml file on each
host, or a specific routers.xml containing only these informations that could
be copied verbatim on each host, and sending a SIGsomething to reload it, but
if you have a better idea you're welcome :-)
--
-- \^/ --
-- -/ O \--------------------------------------- --
-- | |/ \| Alexandre (Midnite) Jousset | --
-- -|___|--------------------------------------- --
