Re: jabberd2 in cluster? ideas, proof of concept and questions...
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.
Re: jabberd2 in cluster? ideas, proof of concept and questions...
About this topic, I have some more comments and questions: Le 15/10/2012 02:22, Alexandre Jousset a écrit : Le 12/10/2012 19:53, Tomasz Sterna a écrit : We do. In the simplest way to do it, routers don't forward other routers' binding requests. Of course it is possible to implement it to allow multi-hops, but I'm afraid this could lead to problems (and inefficiency) for no real gain (except simplistic configuration). Of course it would be easier to only list just one router of the mesh when adding a router, but I would prefer sacrificing this easiness in favor of efficiency. After all, the administrator has all knowledge about its server architecture. So when adding a router, the config file should list *all* other already running routers in the mesh. 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. In my proposal nothing stops you from making each router know all the others to make it more efficient, but it shouldn't be _required_. 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 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. 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. Of course, if you have better solution... :-) -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: Missing images in documentation
Dnia 2012-10-11, czw o godzinie 14:42 +0200, Tomasz Sterna pisze:
> {{{
> yum install jabberd
> }}}
>
> For some reason GitHub's Creole renderer now interprets them as inline
> images of syntax {{...}} :-/
It turns out GitHub made some changes to creole syntax.
http://github.github.com/github-flavored-markdown/
I've fixed and pushed it, so the documentation looks fine now.
