[zeromq-dev] When unreliability is desired

Lindley French lindleyf at gmail.com
Thu Dec 5 21:48:56 CET 2013


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 <lindleyf at gmail.com> 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 <lindleyf at gmail.com> 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 <lindleyf at gmail.com>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 <ivan.pechorin at gmail.com>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" <lindleyf at gmail.com>
>>>> написал:
>>>>
>>>> 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 <lists at 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 <lindleyf at 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 <ph at 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 <lindleyf at 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 at lists.zeromq.org
>>>>>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>> >
>>>>>>> _______________________________________________
>>>>>>> zeromq-dev mailing list
>>>>>>> zeromq-dev at lists.zeromq.org
>>>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> zeromq-dev mailing list
>>>>>> zeromq-dev at lists.zeromq.org
>>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> zeromq-dev mailing list
>>>>>> zeromq-dev at lists.zeromq.org
>>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> zeromq-dev mailing list
>>>>> zeromq-dev at lists.zeromq.org
>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>
>>>>>
>>>> _______________________________________________
>>>> zeromq-dev mailing list
>>>> zeromq-dev at lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131205/76310057/attachment.htm>


More information about the zeromq-dev mailing list