[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Speed of the different discovery providers

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


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.

ecf-dev mailing list