1 person found this helpful
there is no technical limit to the number of neighbors you can have. however, you can't force a client to always be connected to a specific peer. using "NetGroup.addNeighbor()" for a peer that is currently a neighbor (that is, for which you just got a NetGroup.Neighbor.Connect event) doesn't do anything. and if you do add a new neighbor, the group topology manager may automatically choose to disconnect later if that neighbor isn't strictly necessary to maintain the desired topology.
each member of a group will naturally have about O(log N) directly connected neighbors in a group of N peers. the actual number is approximately 2 * log2 N + 13. groups have full transitive connectivity but are not necessarily fully meshed (where each member has a direct-neighbor connection to every other member). groups will typically be naturally fully meshed below about 17 members.
as you've supposed, a full mesh isn't scalable to 100-1000+ members, and there's no reliable way to maintain a full mesh with the existing ActionScript APIs anyway (you can't set a neighbor to be "permanent" in the ActionScript API). note that in a group operating normally, if an average member had 100 neighbors in the steady state, you would expect the group size to be about 2^43 =~ 9,000,000,000,000 (9 trillion) members. groups that large are unlikely.
if you want to send a short message to every member of the group, use NetGroup.post(). that disseminates a message through a group efficiently to each member, but not instantaneously. scalable distributed presence in a very large group is a complex problem. unfortunately, a naïve approach will not be scalable or efficient. i encourage you to search for "newscast" and other "graph diffusion" topics in the context of P2P to get a flavor for how you might approach this problem for very large groups (of like 1000+).
for smaller groups (of up to like 100ish) you can probably get by with having each member periodically posting a presence announcement to the group, and each member keeping track of the age of each announcement it hears, expiring ones after a reasonable timeout.
personally, i wouldn't leave the "everybody" group to do a 1:1 chat.
I see, I guess what was appealing about automatically adding neighbors on the group connect was how when the user got disconnected or left it would give a disconnect event which was great for removing the id from the "online users" array on other clients. I guess I could do something where they periodically do a "post" and maybe they update a timestamp of some sort to show they're online, or maybe use post to remove them if they leave.
Cool, thanks for explaining!