[standards-jig] Distributed JUD
alexey at sevcom.net
Mon Jan 6 12:31:30 UTC 2003
On Sun, 05 Jan 2003 19:01:53 +0100, you said:
>> 2) We make arborescent graph from all servers: every server have "adjacent"
>> servers, and search request from one of them routed to all others. -: If
>> one of servers in down, then we can miss results from segment of servers,
>> also this is not fitted into jabber:iq:search namespace, because this cause
>> multiple responses from different servers (and I dislike idea of sending
>> multiple responses with one ID). Also this can cause many S2S connections.
FF> With a gnutella like search algorithm (i.e. each searver knows only its
FF> neighbours, the search path is a strongly connected graph, not a tree, and
FF> search packets have a time to live) we could bypass the problem of down
Yes, this is much better.
FF> The feseability of this approch depends on the possible s2s traffic due to
FF> search queries, since gnutella doesn't scale well with high traffic
Yes, if we get non-empty search result from e.g. 500 servers, then requesting
server will have 1000 s2s connections. I think this is not suitable.
>> 3) All information is stored on several "root servers". This information
>> is synced between them, and all other servers sends updates of information
>> and search queries to any of them.
FF> My only doubt about this solution is: how much data can grow? Are there
FF> enough entities interested in offering this kind of service, considering
FF> the required storage and bandwith?
This is not technical problem :) Maybe some big jabber servers (jabber.org,
jabber.com, etc) will agree to offer such service.
FF> Updates could also not be very heavy: servers can offer only new items to
FF> other servers, in a nntp style
>> 4) All information is stored on several "root servers", information is not
>> intersected between them, and all other servers sends updates of
>> information always only to one of them. Search queries to one of root
>> servers routed by it to all others root servers.
FF> The biggest problem of this solution is that items can be partioned only
FF> respect to one search field: if I divide the search space among servers
FF> accordingly to the family name, how can I route a query with the nickname?
No, when I write this, I think about partitioning not by some field, but more
by geograpical position (e.g. all russian servers send store information on
jabber.ru, but this is not mandatory). Anyway search requests goes to all root
servers. In comparision with 3), in this case used less disk space, but more
cpu load and traffic.
More information about the Standards