[zeromq-dev] zmq fundamental clarification

[Pieter Hintjens]

Joachim,

You are, presumably speaking of the very specific case of a high
frequency publisher that does nothing except send messages, right?

ZeroMQ isn't optimized for this case, and with the current library the
answer is "no" to all your questions.

However, you could consider a dedicated single-threaded PUB
implementation. I've a simple proof of concept here:
https://github.com/hintjens/zmtplib/blob/master/src/pubz.c

The throughput isn't as high as libzmq because there is no batching,
but latency should be significantly better, without jitter. This is a
TCP version.

If this is a direction you'd like to investigate we can look at what
it would take to turn the PoC into real usable code.

-Pieter



On Fri, Jan 25, 2013 at 10:10 AM, Joachim Worringen
<joachim.worringen at iathh.de> wrote:
> Greetings,
>
> we are considering to use zmq for our very latency-sensitive distributed
> application. zmq offers very compelling features. I searched the web and
> skimmed through the excellent zmq book, but still have some fundamental
> issues:
>
> 1. Is there a way to actually send messages in the context of the
> application thread? Something like "direct send" (or call it synchronously).
>
> Background: The additonal hop between the application thread and zmq i/o
> thread add latency and, most of all, jitter esp. on loaded machines.
> Sending the data directly will improve this, esp. with solutions as
> Solarflare/OpenOnload or similar.
>
> The benchmark data in the Wiki with pingpong/2 of around 30us supports
> this, as we certainly target latencies <10us for this kind of test (and
> we do achieve them easily with direct socket access).
>
> 2. Does zmq support source-specific multicast?
>
> Background: we do not want to set up and maintain global VLANs between
> our data centers. We are forced into doing this for certain reasons now,
> but it's a PITA and we want to get rid of this.
>
> 3. The transparent connection management, and buffering of messages that
> can currently not be sent, is something we need to avoid in certain
> situations. Instead, we'd like to get immediate notification on a failed
> connectione ("remote peer went disconnected"). Is this possible?
>
> thanks, Joachim
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev