[zeromq-dev] zmq fundamental clarification

Niels Berglund niels.it.berglund at gmail.com
Fri Jan 25 20:52:12 CET 2013

As for point 3, regarding disconnection notifications. Sure, so TCP will
not inform you about some disconnections, but for quite a few of developers
of socket based apps, the disconnections TCP informs you of are quite

As far as I understand (based on some tests I have done), the latest
version of 0MQ can give you information about connections as well as
disconnects through the socket monitor. However, the amount of data
available for the user of 0MQ is (to say the least) quite sparse -
basically a file descriptor. Are there any reasons / technical limitations
for not exposing more data - say socket identity and perhaps even some
ip-address information (at the moment the Address information comes out as
"\\" in my tests)?



On 25 January 2013 16:32, Joachim Worringen <joachim.worringen at iathh.de>wrote:

> On 01/25/2013 02:38 PM, Pieter Hintjens wrote:
> > On Fri, Jan 25, 2013 at 2:13 PM, Joachim Worringen
> > <joachim.worringen at iathh.de> wrote:
> >
> >> But 1. is a general concern also for request/reply patterns, and this is
> >> also where 3. matters (which is not relevant to multicast anyway...).
> >
> > Right, though from my unscientific experience, round-trip costs for
> > request-reply are many orders of magnitude higher than the extra
> > latency of asynchronous sending.
> Not sure if we are on the same page here. I'll give my perspective.
> Assuming the request processing takes a few us (as in our application),
> the whole request/reply cycle can be done in 20 to 30us. Handing over of
> the message to the I/O thread (which needs to be woken up if it is not
> polling, and may needs to be scheduled onto the CPU on this occasion)
> alone takes about the same time than sending the message over to the
> other process - certainly for the sending thread.
> The scheduling is the operation that can take ms, and can occur once
> when sending directly, but twice if sending via the i/o thread.
> > Also, TCP won't inform you of certain types of disconnection, so one
> > needs to build some kind of heartbeating in any case.
> Right, and this is what we are doing. Why not let the library do this?
>   Joachim
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130125/454fa19a/attachment.htm>

More information about the zeromq-dev mailing list