Can you clarify where in the Crossroads IO library the UDP transport code lives? I've downloaded the 1.2.0 tarball here: http://download.crossroads.io/libxs-1.2.0.tar.gz but so far, I don't see a UDP transport in that code. I also checked the github version: https://github.com/crossroads-io/libxs but I don't see it there either.
On Wed, Nov 27, 2013 at 11:26 AM, Charles Remes <li...@chuckremes.com>wrote: > 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 <lindl...@gmail.com> 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 <p...@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 <lindl...@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@lists.zeromq.org >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
