[zeromq-dev] When unreliability is desired

Lindley French lindleyf at gmail.com
Wed Nov 27 16:50:21 CET 2013

I've never used ZeroMQ before so writing up a new transport would be just a
bit ambitious right now. (I did write something in Java last year that, in
retrospect, was solving basically the same problem as ZeroMQ so I have some
familiarity with the problem space.)

I'm also leery of adopting a defunct library for a new project.

I'll keep the udp transport option in mind.

On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens <ph at imatix.com> wrote:

> 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 <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
> > 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
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131127/b237b770/attachment.htm>

More information about the zeromq-dev mailing list