I'm trying to make sure I understand how the timer_ids work, since these were not in the Crossroads IO code. It appears several classes define timer_id constants as anonymous enums. Furthermore, the values of these constants don't appear to follow any particular pattern, *except* that constants with the same name (same purpose?) are assigned the same value. Therefore, I expect I ought to adopt tx_timer_id and rx_timer_id from pgm_sender without changing their values for udp_sender etc. Am I understanding this correctly?
On Thu, Dec 5, 2013 at 3:06 PM, Lindley French <[email protected]> wrote: > 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
