On Wed, Mar 23, 2011 at 7:53 AM, Martin Sustrik <[email protected]> wrote:
>> Does this suggest that it would also be possible to query the number >> of connections? That would be very useful for some cases. > > The application can never be sure about how many peers there are. Think > multicast. Or think global distribution tree. It's fine to have semantics that make sense only in some patterns, that's pretty much the definition of a pattern. Benjamin, you've not explained your use case, but I assume it's for req/rep or push/pull, and it's to know things like: * there are zero connected peers, so stop sending, or send somewhere else * all peers are (now) connected, so start sending now only The last one solves the (annoying and frequent) problem of late joiners, in which e.g. the first PULL socket to join can receive tens of thousands of messages during the time other PULL sockets are still connecting. Currently the only solution is to create a separate back channel, it's excessive work for information 0MQ already knows. Whereas if the PUSH socket could report "I have N connected peers" then the app can wait until it has reached some threshold, and then start pushing out messages. It doesn't need to be accurate in real-time, clearly nodes may disappear and still be 'connected'. When you do push/pull or req/rep over an intermediary, the intermediary inherits the problem, which doesn't go away. So Benjamin's suggestion gets a +1 from me. Of course it makes no sense to expose information about peers on a PUB socket, for example. It's an unknown number. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
