Skip navigation
Currently Being Moderated

Question about multicast (many to many)

Jul 20, 2012 5:21 PM

Tags: #air #as3 #connection #netstream #cirrus #stream #netgroups #p2p #multicast #peer

I'm doing some tests with a multicast group, trying to send audio to many and to receive audio from many. My concern is if the amount of people would scale, will it still actually send the audio to every single person in the group? Or just nearby neighbors? I found this property "multicastAvailabilitySendToAll" and set it to true on the sendStream. I couldn't really find a lot of info on this, but from the sound of it. It sounds like it will take care of what i'm worried about.


Also, another issue im seeing is there are times that in small groups, a netGroup.neighbor.connect event never triggers.... at least right away. Then this causes the issue where the new person cant hear anything. Sometimes it actually never connects to any neighbors.


I'm also wondering if it's the convention to not really consider the client "connected" until there is at least the first neighbor connect event.(rather than connecting to the recieveStream) then maybe if there isn't one, after a min, try to connect again.




So basically my question is, will "multicastAvailabilitySendToAll" make sure audio is sent between all clients in the group?


And what to do if time goes by and there is never a neighbor connect event (seems to happen like 15% of the time, not a lot. but it has happened)



And 1 more question, what would be considered a "too many" connected clients for something like this? Does the multicast "mesh" really help something like his scale with little overhead?


My code is pretty simple


protected function setupGroup():void


                                        groupspec = new GroupSpecifier("myGroupName");

                                        groupspec.serverChannelEnabled = true;

                                        groupspec.multicastEnabled = true;


                                        netGroup = new NetGroup(netConnection,groupspec.groupspecWithAuthorizations());

                                        netGroup.addEventListener(NetStatusEvent.NET_STATUS, cirrusStatusHandler);




                              protected function setupSendStream():void


                                        sendStream = new NetStream(netConnection, groupspec.groupspecWithAuthorizations());


                                        sendStream.multicastAvailabilitySendToAll = true;

                                        sendStream.addEventListener(NetStatusEvent.NET_STATUS,cirrusStatusHan dler);





                              protected function setupReceiveStream():void{

                                        receiveStream = new NetStream(netConnection, groupspec.groupspecWithAuthorizations());

                                        receiveStream.client = this;

                                        receiveStream.addEventListener(NetStatusEvent.NET_STATUS,cirrusStatus Handler);




  • Currently Being Moderated
    Jul 21, 2012 1:21 PM   in reply to BryBam

    "multicastAvailabilitySendToAll" controls the timing of how the "hey! i totally have this fragment of this stream! do you want it?" messages (the "availability" messages) as they're sent to your immediate neighbors. if that property is false, availability messags are sent to one neighbor at a time in a round-robin-ish fashion. if it's true, all of your neighbors are notified at the same time.


    you should leave that property set to "false" in most circumstances. it will make sharing more fair in the group and probably reduce overhead traffic.


    that property has no effect on whether the multicast stream will reach all members of the group.  all members of the group, if they're properly connected/meshed, will receive the stream no matter how big the group is.


    a new member isn't part of "the group" until it has at least one neighbor.  of course, if the group only has one member, there will never be a neighbor connect, because there are no peers to be neighbors.


    if a new peer isn't getting connected to neighbors right away, it's probably because it, or too many other peers, are behind NATs or firewalls that RTMFP can't make P2P connections through.  certain combinations of NATs can prevent two peers from communicating; for example, if the two peers are each behind symmetric NATs, or if one is behind a symmetric NAT and the other is behind an address- or port-restricted cone NAT, then RTMFP communication won't work between those two peers.


    multicast works best for 1-to-many or small-number-to-many.  in the case of everybody-to-everybody (N-to-N), you will have exactly the same number of streams and data flowing through the group as if you built the mesh manually out of N 1:1 connections, but the multicast overhead is much higher than 1:1 streaming.  it might be easier to manage programatically with multicast streams, and you'll only have O(log N) direct P2P connections instead of O(N), but you'll still have O(N) stream data flowing in and out of every peer.


    you'll probably also run into limitations with the number of simultaneous NetStreams you can have going at once before some unfortunate O(N^2) things in the NetStream implementation start to catch up to you.



    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points