Okay, I'm working on porting the UDP stuff to the latest ZMQ now. Most of the changes necessary are purely a matter of namespace, but there are a few others that seem to reflect design changes in ZMQ since XS was forked. These are the ones I'm not immediately sure how to solve:
1) The XS UDP code references encoder_t and decoder_t, but ZMQ has v1_encoder_t and v2_encoder_t etc instead. 2) i_engine appears to have three pure virtual methods that are not defined in the XS code: restart_input, restart_output, and zap_msg_available(). Any suggestions how to resolve these? On Thu, Dec 5, 2013 at 10:52 AM, Lindley French <[email protected]> wrote: > Thanks, I found it. I don't see any reason given as to why UDP support was > reverted, though. Are there issues with the code, philosophical objections, > etc? > > > On Wed, Dec 4, 2013 at 5:16 PM, Ivan Pechorin <[email protected]>wrote: > >> 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 >> >> >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
