[zeromq-dev] When unreliability is desired
ph at imatix.com
Tue Nov 26 19:18:49 CET 2013
The right solution would be to make a UDP transport for ZeroMQ. It's
not a trivial project but could start with, for instance, just pub/sub
It might be worth looking at Crossroads.io for that, which is
abandoned but had afair a UDP transport, and shared the same original
codebase with ZeroMQ.
On Tue, Nov 26, 2013 at 6:15 PM, Lindley French <lindleyf at gmail.com> wrote:
> 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
> 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.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev