Le 18/10/2012 16:42, Tomasz Sterna a écrit :
Dnia 2012-10-18, czw o godzinie 16:12 +0200, Alexandre Jousset pisze:
What if you do not manage all the routers in the mesh?
And you were given a password to access only one or two routers of the
mesh?
I think it is pretty unusual for the admin not to have access to all
routers (at least all routers managing the same domains). I'm sure there could
be cases and this would add a lot of flexibility, but see below for the
drawbacks.
I've been building collaborative mesh networks (ircd, eggdrop) a lot.
Believe me, the situations when you have just an entry point to the
network are not that rare.
Besides, it goes along the philosophy of jabberd2.
router-users.xml is there for a reason.
If it was assumed one administrator controls the whole components
network, there would be no need for separate users.
The problem with the multi-hop proposal is that you have to manage cases where
there is cyclic connections. e.g. A => B => C => A
What exactly is the problem with cyclic connections?
A solution may be to add the ID of the component binding the domain /
bare JID to the bound route, and to check if that combination is already bound,
but this will increase CPU usage and the data structure sizes.
TTL/distance would be enough.
This does not increase data structures that much and CPU use is
neglectable - you have to choose the route anyway.
"Premature optimisation is the root of all evil." - let's concentrate on
the design first.
Now that I think of it, implementing distance would be beneficial
anyway, as we could mark routers on slow connections as less preferable.
For the moment I have 2 hash tables (finally I differentiated them), one for
domains where we don't really care of the size of the values, and one for bare JIDs
bindings where the value is just the component_t. This component_t can be the local
component for local connections, or other routers connection for remotes. So we would
have to add a "char *" malloc'ed, strcpy'ed, etc., for each new connection in
bare JID binding mode. So this would add CPU and memory consumption just for multi-hop
support. It's a choice to do, if you really want me to do this I'll do it, but I'm a bit
against that solution.
I'm sorry, I don't understand.
Give me for-instance.
Forget about all this ;-) As I was writing a response to this post I
understood that my problem was an implementation issue indeed, and I found a
solution for it ;-)
Roughly, instead of storing a component_t as bare JID hash table values I'll
store a pointer to an element of a pool of "component_t / component ID /
distance" associations.
--
-- \^/ --
-- -/ O \--------------------------------------- --
-- | |/ \| Alexandre (Midnite) Jousset | --
-- -|___|--------------------------------------- --
