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.
