1 Reply Latest reply on Jan 16, 2012 11:47 AM by Michael Thornburgh

    High latency when using Group based RTMFP communication




      It is possible to stream data to another peer directly by setting up a netream using NetStream.DIRECT_CONNECTIONS. It is also possible to stream data to a group by setting up a NetGroup and defining a GroupSpecifier to configure this. I setup a simple one-on-one audio and a one-on-one video connection using both methods and the strange thing is that the direct communication has much lower latency.


      1) Does anyone know why, and what I can do to resolve this? (I would like to use group communication because this would make switching to a 3 party conversation easier)


      2) In the beginning the latency is worst, but after a little while the situation generally gets a little better. Why is this?


      I need to find a way around this because communicating with the delay currently encountered is not feasible.


      Thanks in advance

        • 1. Re: High latency when using Group based RTMFP communication
          Michael Thornburgh Adobe Employee

          1) the delay is part of the design of our P2P multicast system.  the delay is necessary to give subscribers an opportunity to obtain pieces of the stream from their peers. the NetStream.multicastWindowDuration controls how long a subscriber will try to obtain the data, after which it gives up and the data is just declared missing. the window limits the amount of jitter you can expect (the default is 8 seconds). decreasing the window can decrease latency/jitter, but will also decrease reliability (that is, increase the number of gaps/glitches you'll see in the stream).  if you make the window very small, there might not be enough time for group to do the necessary work to propagate the stream beyond a very small number of subscribers.


          2) the group automatically tunes itself trying to reduce the propagation latency and increase efficiency and sharing fairness, by building a number of parallel "push" spanning trees through the group. in a completely stable group where nobody joins or leaves, the propagation latency can eventually get very short, but groups are never really that stable. any disruption to the push mode will require falling back to the default pull mode to fill in a missing piece, and again that's what you need the window for.


          note that in an N-to-N way conversation (example: 3 party conversation, everyone's streaming simultaneously), it's actually more efficient to build your mesh out of DIRECT_CONNECTIONS streams. with P2P multicast everyone needs to receive each stream, which means each copy for each peer needs to come from somewhere (which means the other peers). so on average the bandwidth would be exactly the same, except that the multicast stream has additional overhead associated with it, which isn't present in DIRECT_CONNECTIONS streaming.


          for more about how the P2P multicast system works, please view Matthew Kaufman's session from MAX 2009: