[zeromq-dev] When unreliability is desired

[Ivan Pechorin]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131205/a93344e2/attachment.htm>