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. > 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. > thought "why not use a single flat hash table that could be used as a > tree as well?". It's a detail but I think it simplifies some > implementation details. Yeah. Why not. :-) I like this idea. Greatly simplifies the implementation. 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 '' ?) > This way a router connected to another router can be seen, for > the routing purpose, as a normal component. What do you think about > this? Yes. I like the idea. > So, in the hash table values structure, one can store a linked > list of possible routes (which is a structure containing a > component_t, a priority and a "next" pointer) sorted descendant by > priorities, and an enum containing the request type for this entry > (domain, bare JID or full JID). Right. > 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. > 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. If we would enforce the rule, that component names cannot contain dot (.) we would minimise possibility for collision with domain name. > [...] 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? :-) But I would leave the answer to this question for later. -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
