[standards-jig] Distributed JUD

Fabio Forno f.forno at kamin.polito.it
Mon Jan 6 18:21:43 UTC 2003


Alexey Shchepin wrote:

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

Indeed several improvements have been made in broadcast search queries. 
Results could be sent not to the requesting server, but to the previous 
hop, which could merge and cache results. In this way we would receive 
answers only from our neighbours.
Anyway there are still many drawbacks, since queries will be necessarly 
slower than those issued against a central server, and it will be CPU 
intensive for intermediate hosts.
One more pro is spam prevention: all users' lists are never published, 
since they haven't to be synched or exported to others


> This is not technical problem :)  Maybe some big jabber servers (jabber.org,
> jabber.com, etc) will agree to offer such service.

I know, but good technical solutions are worthless if there is nobody 
wanting to embrace them ;)


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

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

Finally for the solution 3 or for the central servers and crawlers that 
others have proposed, a pub/sub mechanism could be considered. Servers 
wanting to expose their users have just to advertise themselves to a 
pub/sub component somewhere, and indexers just wait for some new event

-- 
ByE, FF
"NOBODY expects the Spanish Inquisition!"
jabberid: sciasbat at jabber.linux.it




More information about the Standards mailing list