Re: [ecf-dev] Speed of the different discovery providers

[ahmed.aadel@xxxxxxxxxxxxxxxxxx]

I think the notion of unicast/multicast
is irrelevant in zooDiscovery context.  A client doesn't connect to
a server to,first hand,  get registered services on one of its nodes.
A client connection in zooDiscovery context is a registration as a node
listener so that this client gets called back by the server itself every
time there a change (in our case, a service un/registration). So, it's
not one re/connection per discovery intent, This implies the work-load
is on the server itself notifying in a serialized manner its clients/listeners
of all occurring changes. That work-load also depends on how many servers
you are deploying (specified by which configuration flavor).

Ahmed

From:	Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>
To:	"Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>
Date:	28-01-2011 15:11
Subject:	Re: [ecf-dev] Speed of the different discovery providers

---

On 01/28/2011 02:25 PM, ahmed.aadel@xxxxxxxxxxxxxxxxxx
wrote:

>>Zookeeper and SLP/JmDNS work quite differently. Where SLP/JmDNS
use
>>multicast, Zookeeper uses a unicast connection. Thus Zookeeper
will be
>>naturally faster (for small numbers of client), but it has the
drawback
>>that it requires client configuration (IP of Zookeeper server).
> 
> This statement is based on what facts?
>><..> (for small numbers of client)

On the fact that Zookeeper requires one unicast connection per client
(doesn't it?).
With large numbers of clients, a multicast connection will considerably
reduce the amount of messages it takes to communicate among all clients.

Markus
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev