[standards-jig] Distributed JUD

Alexey Shchepin alexey at sevcom.net
Wed Jan 8 16:45:46 UTC 2003


Hello, Fabio!

On Mon, 06 Jan 2003 19:21:43 +0100, you said:

 >> 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.

 FF> Indeed several improvements have been made in broadcast search
 FF> queries. Results could be sent not to the requesting server, but to the
 FF> previous hop, which could merge and cache results.

Merging of replies it seems not very good idea, because it need to wait for all
servers, and if one of them drop query, then we will reach some timeout value,
that can be annoying for peoples.  So better to redirect replies to requesting
host immediately.  But in this case we need to slightly change iq:search
protocol.

 >> 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.

 FF> Understood, it could be like solution 2 with just some super-servers take
 FF> part to the distributed JUD. In this case I like the idea, since it could
 FF> lead to some interesting features. For example two big friend companies
 FF> could be interested in sharing between them a greater part of their
 FF> employees' data than they reveal to the rest of the world. They could
 FF> build a common JUD server taking part to the distributed JUD netowork, and
 FF> this JUD would anser queries on some fields only if they come from their
 FF> inner networks.


Yes, and this method can be combined with second: we have searchable servers,
that virtually connected into gnutella-like network, and other servers, that
store information and send queries to one of them.  E.g. if I have
low-bandwidth connection and don't want to receive several search queries every
second, then I can store my information on one of searchable servers.  More big
servers, can register yourself as searchable server.  BTW, if we have only one
searchable server, then this method works as first solution.




More information about the Standards mailing list