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.
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?
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.
Thanks a lot for answering. The 16 limitation won't be a problem for me, but still it is good to know...
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.
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.
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?
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.