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() function is called, the following options would need to be invoked: 1) These options cause the NORM sender to always accept new messages enqueued even if older messages in its transmit buffer are pending repair transmission. This way the real-time delivery of the video stream is maintained regardless of network conditions. I.e., reliability is attempted within network round-trip time and buffering constraints, but otherwise the video stream delivery "pushes ahead" regardless. To support this the congestion control feature should also be disabled and a fixed transmit rate suitable to support your video stream should be set. NormSetFlowControl(norm_session, 0.0); NormSetPushEnable(norm_session, true); NormSetCongestionControl(norm_session, false); NormSetTxRate(norm_session, <bits / sec>); 2) The NormSetAutoParity() call can be used to add some portion of erasure-filling Forward Error Correction (FEC) code "parity" packets to the video stream. The current norm_engine code sets modest FEC parameters in the call to NormStartSender() made in norm_engine::init() in norm_engine.cpp. The NormStartSender() FEC parameters are the "numData" and "numParity" values which determines the number of user data (e.g. video content) packets per each logical coding block and the "numParity" parameter is the number of FEC parity packets computed and cached per coding block. Normally, these computed parity packets are not transmitted until the receiver(s) send a NACK asking for repair. However, the "auto parity" feature allows the sender to be configured to send some portion of those packets alongs with each block of user data packets. Erasure coding is used that treats "packets" much the same way that a disk volume is treated in a RAID array. Similar to how if a disk fails, the RAID can recover itself, the use of erasure coding in NORM allows missing packets to be recovered. For example, if the "numData" value is 16 and the "auto parity" value is set to 2, NORM will transmit 18 packets for every 16 packets of user data and the receiver can lose any 2 of the packets for the block and still recover the data as if no packet loss occurred. In fact the receiver application can call NormSetSilentReceiver(norm_session, true) to disable NACKing and receive content with some measure of reliability without sending any feedback to the sender. With receiver NACKing disabled _andy_ zero auto parity, NORM essentially then provides something like UDP best effort message delivery (while still doing fragmentation and re-assembly for messages larger than a single packet payload) 3) Another aspect of the NormStartSender() call is the "stream buffer" size that is set. This determines how much buffering the sender and receivers use. With "push enabled", etc and quasi reliable delivery, the buffer size determines the maximum latency (due to buffering) for a given video rate. So the buffer size can be adjusted accordingly. Currently there are not socket options in the ZeroMQ API to adjust NORM in these ways. One possibility would to have a different, variant "norm" protocol type (e..g "normv://<address>/<port>" to denote "norm video" transport or something? For the moment, if you wanted to hack up the "norm_engine" a little bit to try this, I would be happy to help out. cheers, Brian On Mar 25, 2014, at 7:01 PM, Pieter Hintjens <p...@imatix.com> wrote: > There's no explicit retransmissions in 0MQ, though TCP will do that > for dropped packets. > > On Tue, Mar 25, 2014 at 11:48 PM, George Kumar <grgkum...@gmail.com> wrote: >> Hi Pieter, >> >> Does PUB-SUB do retransmissions at the TCP level ? We do not need >> retransmissions as that will impact the real time nature of our application. >> Even though pub-sub is unreliable overall, I am wondering if retransmissions >> happen to make sure a message is reliably delivered. Having a flag that >> says "no retransmissions" will also be helpful. >> >> Thanks. >> George >> >> >> On Fri, Feb 14, 2014 at 1:40 AM, Pieter Hintjens <p...@imatix.com> wrote: >>> >>> George, >>> >>> You can probably send video to a handful of recipients over TCP, using >>> pub-sub sockets. It depends totally on the video size, compression, >>> etc. UDP multicast isn't going to help unless the recipients are on >>> the same network. Semi-reliable UDP (like UDT) might help on some >>> networks. However TCP will mostly do just fine for your case. >>> >>> -Pieter >>> >>> On Wed, Feb 12, 2014 at 1:24 AM, George Kumar <grgkum...@gmail.com> wrote: >>>> Hi all, >>>> >>>> Sorry if this too basic a question for most for you on the list. I have >>>> a >>>> requirement where I need to multicast video to up to 3 recipients. I am >>>> considering ZMQ PUB/SUB model. But ZMQ does not have the option of using >>>> UDP >>>> for transport. TCP is generally discouraged for real time data like >>>> video. >>>> So what do you folks think ? >>>> >>>> Appreciate your feedback. >>>> Thanks. >>>> George >>>> >>>> _______________________________________________ >>>> zeromq-dev mailing list >>>> zeromq-dev@lists.zeromq.org >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> zeromq-dev@lists.zeromq.org >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> >> >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
