[zeromq-dev] zmq fundamental clarification

[Joachim Worringen]

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