Hi Lionel,
Although it isn’t yet supported with the ZMQ API’s, the NORM protocol can be
configured with receiver feedback disabled to provide an unreliable UDP-like
best effort service with the added benefit of its message fragmentation and
reassembly when messages are larger than the network
It was a great honor to have interacted with Pieter and his energy, willingness
to help, awesome code, and leadership here were exemplary. I offer my deepest
sympathies to his family and those who knew him well.
Brian Adamson
> On Oct 4, 2016, at 10:29 AM, Benjamin Henrion <zoo...@gma
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
Another option here is the NORM protocol. One thing to note is NORM in ZMQ
uses its default TCP-Friendly congestion control mechanism by default. For
lossy wireless links, this particular congestion control approach uses packet
loss as a congestion indicator just like TCP and thus has similar
As I think MinRF is getting at here, you need to make sure your pyzmq you are
using is loading the libzmq that you built/installed with the NORM extension.
On my systems, I had to download and install pyzmq from source code instead of
one the prebuilt packages that assumed a dependency on an
I concur with Steve-o's comments. The current NORM transport option in the git
repository has some middle-of-the-road parameter settings with regards to
performance. It does do TCP-friendly congestion control. It is set for a
modest level of the FEC erasure coding it uses for a highly
The norm_engine code be easily adapted to provide best effort to
quasi-reliable, to reliable real-time video messaging for unicast or multicast
destination addresses. The following options would need to be set on the
NORM sender / publisher session initialization:
Before the NormStartSender()
regards,
Brian
On Mar 14, 2014, at 6:43 PM, Brian Adamson brian.adam...@nrl.navy.mil wrote:
Hello,
I had ported our NACK-Oriented Reliable Multicast (NORM, RFC 5740) protocol
implementation into a copy of the libzmq 4.0.3 source tree and it working
with some test code implemented
I have submitted a follow up pull request to fix the issue. Due to my
unfamiliarity with 'git' the first pull request didn't include some final edits
I had made in my fork. I'm still getting used to the git commit/push steps
versus 'svn commit'.
Sorry about that! Definitely didn't mean to
.
-Pieter
On Sat, Mar 15, 2014 at 3:22 AM, Brian Adamson
brian.adam...@nrl.navy.mil wrote:
As mentioned in the thread with the question regarding the
encoder::has_data() method deprecation, here are some notes on the
norm_engine adaptation...
On 14 March 2014 18:43, Brian Adamson brian.adam
Per Pieter's suggestions, I have posted the writeup in a more readable form to
the ZeroMQ Wiki at:
http://zeromq.org/topics:norm-protocol-transport
I also have issued a pull-request (I think - I'm somewhat of a git newbie) for
this candidate extension.
Note that the question of reinstatement
be resolved, I can issue a pull request for this norm_engine code as well.
best regards,
Brian Adamson
brian.adam...@nrl.navy.mil
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
API
and its ZeroMQ adaptation can be expanded.
Brian Adamson
mailto:brian.adam...@nrl.navy.mil
12 March 2014
On Mar 14, 2014, at 8:11 PM, Steven McCoy steven.mc...@miru.hk wrote:
On 14 March 2014 18:43, Brian Adamson brian.adam...@nrl.navy.mil wrote:
Also, I have a short overview/write-up
13 matches
Mail list logo
