Dnia 2012-09-06, czw o godzinie 00:29 +0200, Alexandre Jousset pisze: > > 1) A minor one: is it right that it's a typo when you wrote > > example.org instead of example.com at some places? > Obviously, yes.
Right. Assume one domain. > > 2) Is is OK to assume that all non full-JIDs are of priority 0 (or, > > better said, have no priority at all)? > Obviously, yes. I'm thinking: - domain level - priority configured in component.xml (ie. sm.xml) configuration file, passed to router on connection. This allows to have load balancing (same priority) or one main component (higher priority) and backup(s) (lower priority) - bare-JID level - highest priority bound to user resources on SM. SM keeps a notion of "top" resource used to deliver messages directed to bare JID. Using this resource priority will make the component catch messages passed to bare-JID See: https://github.com/Jabberd2/jabberd2/blob/master/sm/pres.c#L40 - full-JID - just use the bound resource priority There is one caveat here. With current implementation, if user has two bound resources with the same priority, we pass the message to this priority to both connections. If we do it on router level, with current "select one randomly" it will break this implementation. We may need to think what would happen if we would implement "pass to both connections" at the router level. Maybe it would work even better than the random approach. :-) > > 3) I have a doubt when you say at different places that a component > > needs to bind bare-JIDs / full-JIDs "from now on". Does that mean that it > > needs to send bind requests for all sessions it already has, or just make > > *new* bind requests of the type you mentioned? > I think the component has to send all its already online sessions. Yes. If a component gets a request to change the "binding level" it needs to bind/unbind all pending resources (ie. bind all known bare JIDs if upgrading from domain level bind) and keep binding new connections at the current "binding level". > And I think this can be a hint for the routers' synchronisation in > multi-router implementation. In a multi-router implementation, why not > consider a router as a more or less "normal" component (when connected to > other routers)? With one exception, that when a random has to be chosen > between components, only the local components have a chance. I have to think > more about this... We cannot as router does not have a domain it keeps all other connections under. You can have every possible combination of resources at any router. Router just have names like every other component on the network, that may be used to pass packets to. What could work? Let's imagine a routing table like this: JID(prio) | destination | where did I get it from [email protected]/deedbeef(1) sm31 router7 .... . null(4) | sm31 | router7 So, when you get packet directed to [email protected]/deedbeef, you know that it needs to go to sm31. Since sm31 is not your local component, you need to find sm31 component. You find that souter7 component knows it, so you pass the packet to router7 connection and you're done. > > 4) In this process, what if component1 disconnects? I suppose that the > > router needs to crawl through its tree to update it, but that can be CPU > > intensive and can cause lags... I know that this event is not a "normal" > > event anyway and is not supposed to happen often, so it can be negligible. In case of local component, just find the node containing the disconnected component, and iterate through all nodes and "disconnect" them. It's not that hard or slow as you may think. It's fast and happen in jabberd2 code many, many times. We have a very fast hash-table implementation. :-) See: https://github.com/Jabberd2/jabberd2/blob/master/util/xhash.h If you have remote router connections, you just broadcast the component disconnections to them, the same way it is broadcasted to local components. In case of remote component disconnection, you just remove the entries for the component from your routing table. Simple. > > 5) A Jabber protocol question, I know I could find the answer in the > > online docs, but as I have you at hand ;-) Is it possible to have 2 > > full-JIDs connected at the same time? With equal or different priorities? I > > suppose the answer is "no" to both questions, but just to be sure... > Obviously, no. Full-JIDs need to be unique. See: https://github.com/Jabberd2/jabberd2/blob/master/sm/sess.c#L141 > > > 6) The tree structure I'm thinking about uses hashes to find the next > > node (root => domain => user => resource), and finally a pointer or an > > array of pointers to components for the leaves. If the answer to previous > > questions at 5) is "no", there is only one case where there can be more > > than one leaf: at each node is a "default route" leading to one or more > > components. If I use a static sized array to store them, that will use more > > memory. So the best would be to use a linked list, but that would make the > > process slower. I would tend to use linked lists because the cases where > > one has to crawl through them are (relatively) less frequent. What do you > > think? > > Stupid question: the case where there is multiple choice for components > is only the "domain" case. So I can use a reasonnably > configurable-at-compile-time sized array. Not really. You can have multiple bounds on bare-jid level also. There can be several components handling '[email protected]' connections. Each with separate set of '[email protected]/something' full-JIDs. Look at the current implementation: https://github.com/Jabberd2/jabberd2/blob/master/router/router.c#L159 And just extend it to e tree structure, with current implementation at each node. :-)
