8 Replies Latest reply on Dec 16, 2010 6:51 PM by Michael Thornburgh

    multiple netstreams V.S. multiple netgroups

    Carrie Wang

      I have a netgroup that contains multiple publishers, I am wondering what is the most efficent way to do multicasting to a subset of members.

       

      1. each publisher publish a unique netstream to the group, and members can choose which netstream they would want to play.

       

      2. each publisher create a unique netgroup, and members can join different netgroups to play the stream.

       

       

      To my understanding, the first way is not very efficent since everyone in the netgroup would recieve a post notification no matter they play the stream or not. But how much will this effects the performance?

       

      About the second way, I am not sure if it would work or not. Can I keep a user in multiple netgroups?( both the orignal group that contains everyone and the publisher's group)

        • 1. Re: multiple netstreams V.S. multiple netgroups
          Michael Thornburgh Adobe Employee

          you want way #2.  every member of a group receives the stream data flowing through the group, whether they play it or not.

           

          Flash Player has no limitation (beyond memory) for the number of different groups it can join.  note however that being a member of a group with multiple members incurs network overhead for the group topology protocol even if the group is otherwise quiescent.

           

          Cirrus has a limit of 16 groups per client for which it will perform automatic group bootstrapping.

          • 2. Re: multiple netstreams V.S. multiple netgroups
            Carrie Wang Level 1

            Thank you so much for the reply.

             

             

            When you say "16 groups per client", what does the client refer to? the developer or the end user?

            • 3. Re: multiple netstreams V.S. multiple netgroups
              Michael Thornburgh Adobe Employee

              the end user.  specifically, a NetConnection.

               

              for each NetConnection a client (Flash Player, AIR, etc) makes to Cirrus, Cirrus will do automatic group bootstrapping for the first 16 simultaneous/concurrent groups with "serverChannelEnabled=true".  you can join a 17th simultaneous/concurrent group from that NetConnection, but Cirrus won't bootstrap it to anyone else, so it'll be lonely.  you can implement your own bootstrap service, though (and use NetGroup.addNeighbor()).

               

              note the limit is on simultaneous/concurrent memberships in groups, not total joins of groups.  so you could join (and be automatically bootstrapped into) a thousand groups, as long as you weren't in more than 16 at any one time.  although please don't do that.    note also this limitation is an administrative limit intended to protect the service from accidental or intentional resource exhaustion, not a technical limit.  if you have a reasonable use case for being in more than 16 groups, let us know and we might up the limit.

              • 4. Re: multiple netstreams V.S. multiple netgroups
                Carrie Wang Level 1

                Thanks a lot for answering. The 16 limitation won't be a problem for me, but still it is good to know... 

                • 5. Re: multiple netstreams V.S. multiple netgroups
                  Ric Moore

                  Hi Michael,

                   

                  I'm building a multiplayer game where each player in a match sets up a group and all the other players subscribe to it. That way each player can multicast their location etc to all the other players.

                  This means currently that you can only have a maximum of 16 players in a game. It would be cool if you increased this number to say 32 or 64. I imagine Flash will struggle with 64 players but I'd like to be able to test this limit.

                  • 6. Re: multiple netstreams V.S. multiple netgroups
                    Michael Thornburgh Adobe Employee

                    if in a match all of the players are in the same match (that is, all of the groups you're envisioning would have the same members), then it would be way more efficient to have just one group.  you can have as many multicast NetStreams in a group as you want; they just need different names.  your peerID (NetConnection.nearID) is a good name choice, since it's unique.

                     

                    you can have as many NetStreams and NetGroups as you want; as long as they have the same groupspec, they are the same *group*, and only count once for the server channel to Cirrus.

                     

                    remember that each group has about 2kbps of maintenance/overhead background traffic even if otherwise completely idle.  so if you have 64 players and each has their own group, then that's 128kbps of bandwidth *each player* will be using just to be in all those groups, but if they're all sharing one group, then that's just 2kbps for each player.

                     

                    if you really really want a separate group for each player, then there's an easy way to avoid the Cirrus bootstrap limit: use GroupSpecifier.addBootstrapPeer() to make the host/owner of that group be the bootstrap peer, and don't enable the server channel.

                    • 7. Re: multiple netstreams V.S. multiple netgroups
                      Ric Moore Level 1

                      I'm still reading up on Cirrus but isn't a group owned by 1 client?

                      If it is this causes a few problems:

                      - it's very open to being hacked

                      - if that client goes offline the whole game ends.

                      - if that player has a slow connection, everyone suffers

                       

                      I was thinking a secure p2p solution might involve each player being part server, so each player has it's own group and all the other players subscribe to it. Then when the player moves/fires it multicasts via that group to all the other players. The other players can then do some basic validation on the moves to make sure it's not been hacked. The other advantages would be that if a player goes offline then just that player vanishes. Or if a player is having latency issues then only their avatar will be affected in the game.

                       

                      This 2kps overhead sounds big. One group would be ideal but can all the players be owners? How would you suggest tackling this problem?

                      • 8. Re: multiple netstreams V.S. multiple netgroups
                        Michael Thornburgh Adobe Employee

                        no, a group is not owned by one client.  it is a cooperative, decentralized, distributed system.  don't think of it as a service you connect to, but rather as a system you become an equal part of.

                         

                        the only thing that distinguishes special members from regular members of a group is, if there are passwords associated with multicast publishing or posting, then only those members with groupspecs containing the authorizations will be able to do those things in the group.