It appears that at some point, activate_in was renamed to restart_input, and likewise with output. I'm assuming there are no functional changes other than the names in the UDP case. It also appears that zap_msg_available() can be ignored for now. Let me know if I'm wrong about these.
On Thu, Dec 5, 2013 at 2:01 PM, Lindley French <[email protected]> wrote: > 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
