That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported.
On Nov 27, 2013, at 9:50 AM, Lindley French <[email protected]> wrote: > 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 <[email protected]> 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 <[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 > > _______________________________________________ > 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
