[zeromq-dev] UDP without PGM

[Brian Adamson]

The NORM transport engine can also provide a UDP-like delivery service and on top of that will do segmentation/reassembly of larger messages and can have proactive packet erasure FEC added to the stream for additional quasi-reliable robustness.  _But_, those features are not yet exposed as options through through the ZeroMQ API.   If someone is interested in that, I would be happy to discuss it further.

best regards,

Brian


> On Apr 26, 2016, at 9:43 AM, TL;DR <tldr1969 at gmail.com> wrote:
> 
> Oh thats great!  I'll check out a copy of the development tree to play around with it.
> 
> On Tue, Apr 26, 2016 at 2:54 AM, Doron Somech <somdoron at gmail.com <mailto:somdoron at gmail.com>> wrote:
> Zeromq now have UDP transport, which you can use with the radio-dish socket types.
> 
> No docs yet so take a look at the following test:
> 
> https://github.com/zeromq/libzmq/blob/master/tests/test_udp.cpp <https://github.com/zeromq/libzmq/blob/master/tests/test_udp.cpp>
> 
> Both multicast and unicast should work.
> 
> On Tue, Apr 26, 2016 at 6:26 AM, Ben Kloosterman <bklooste at gmail.com <mailto:bklooste at gmail.com>> wrote:
> Just leave the UDP ..  I use UDP  as a separate channel and its so different that it should always be considered different eg no guarantee , no packet > 64K / MTU  etc etc Forcing it to the sane structure is likely to be a bad idea.
> 
> Ben
> 
> On Tue, Apr 26, 2016 at 8:10 AM, TL;DR <tldr1969 at gmail.com <mailto:tldr1969 at gmail.com>> wrote:
> Hi, I just wanted to kick this conversation again.
> 
> Does anyone have any pointers to patches or experimental versions that provide UDP datagram transport without PGM?  Just plain UDP for unicast/multicast.
> 
> I have migrated pretty much all services in a system over to ZeroMQ.  But there is a use case where I use UDP today, and haven't been able to do so.  I'm thinking there must be others (esp in finance) who are in the same boat.
> 
> PGM is a non-starter because auto-magical but late delivery is worse for us than no delivery in this use case.  These particular applications have more complex behavior when they have missed something, and there is a favored application level mechanism for detection of missed messages and recovery.
> 
> Thanks for any advice,
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev <http://lists.zeromq.org/mailman/listinfo/zeromq-dev>
> 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev <http://lists.zeromq.org/mailman/listinfo/zeromq-dev>
> 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev <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/20160426/e9bc54ce/attachment.htm>