Hi Lindley, 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 (like PGM).
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. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French <[email protected]> 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 > 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. > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
