Le 11/09/2012 13:35, Tomasz Sterna a écrit :
Dnia 2012-09-10, pon o godzinie 19:40 +0200, Alexandre Jousset pisze:
with separate set of '[email protected]/something' full-JIDs.
Ok for this. I'll use linked lists, which will be pretty small
after all (and ordered, too).
Or you can just stick to one routing table for all connected components
and routers in one xhash.
Should be simple and work fine.
This is what I'll do, I was talking about the routes stored (ordered by
priority desc) in the structure pointed by the hash value. Sorry for not being
clear.
Of course I'll try to minimize the changes. Anyway, as in my
previous attempt I've set up 2 options for the configure script:
--enable-adaptive-routing and --enable-cluster (<= should I change
this last one to --enable-router-mesh? ;-) ) that activate these
functionalities that should be marked as experimental for a while.
Just drop it.
It makes no sense in maintaining two separate routing strategies.
The one we are talking about should work as good as the current
implementation in simple deployments with just single router component.
Ok.
[...]
So ie. for incoming packet to '[email protected]/foobar' you would look
for component/router bound to '[email protected]/foobar',
if not found look for '[email protected]',
if not found look for 'example.com',
if not found use default route (look for component binding '' ?)
Exactly.
[...]
About the default route(s), they could be stored in the hash
table using the same schema (using a special hash key), so there could
be more than one "default route" (with, e.g., a constraint about not
being possible to have 2 default routes with same priority).
I would just bind "" (empty string) or null and use the same hash-table.
Ok.
Components like sm and c2s could be stored the same, using
just the "domain" part of the JID, as it is the case now.
Components have its own names.
Each component needs to be uniquely named.
Yes.
If we would enforce the rule, that component names cannot contain dot
(.) we would minimise possibility for collision with domain name.
Ok.
[...] Just a note about the routing table sharing, when a component
is requested to send binds for all its sessions, this could be done in
a bulk way. Same for unbinding. And this bulk could be forwarded as-is
to other connected routers.
This is the easy part.
The real issue is when you have a working mesh that got split in two
parts and worked for some time independently.
How do you recover from this split when parts get reconnected? :-)
Well, why not behave as if it was a "normal" bind?
I haven't thought a lot about it, I definitely need to do it, but in my
first thoughts there can be collisions on JID's resource parts. This is why I
asked if the resource could be renamed *after* a session is started...?
But I would leave the answer to this question for later.
When I read that sentence, I think I haven't thought enough about a lot
of problems that could arise at that reconnection time :-p So I'm eager to read
your answers ;-)
--
-- \^/ --
-- -/ O \--------------------------------------- --
-- | |/ \| Alexandre (Midnite) Jousset | --
-- -|___|--------------------------------------- --
