[zeromq-dev] When unreliability is desired

[Lindley French]

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/1222a3f9/attachment.htm>