UDP support was reverted in libxs just before 1.2.0 release: check the commits history on github around June 13th, 2012. 05.12.2013 6:48 пользователь "Lindley French" <[email protected]> написал:
> 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 <[email protected]>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 <[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 >> >> > > _______________________________________________ > 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
