[zeromq-dev] When unreliability is desired

Lindley French lindleyf at gmail.com
Tue Nov 26 18:15:44 CET 2013


I have a networking application that I'd like to use ZeroMQ in. However, my
use-case demands minimum latency even at the expense of lost messages. I'm
weary of using ZeroMQ's TCP transport because if packets are dropped, TCP
will block further messages until it has retransmitted the last one, and I
don't want that behavior.

I don't mind FEC codes or other strategies to improve reliability by
sending more data up-front, but I do not need complete reliability and I
want to avoid retransmission of messages, or at the least avoid blocking
later messages if earlier ones need to be retransmitted.

Is there an existing ZeroMQ transport that will provide the behavior I
want? I was thinking maybe epgm would do the trick, even though I don't
really need multicast. Ideally, I'd want a transport that uses pure UDP for
messages, perhaps with some TCP "behind the scenes" for out-of-band
handshaking.

I may end up just using UDP myself for the time-critical messages, and
ZeroMQ for less critical data, but I'd prefer to avoid multiple-API creep.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131126/bbd1d987/attachment.html>


More information about the zeromq-dev mailing list