Few questions about netGroup neighbors limits

Question

I'm playing around with a p2p messenger type of client where i'm catching neighbors when the netgroup.neighbor.connect event goes off, and then using add neighbor by adding their peerID (not the neighborID, i'm not really quite sure how/why that would be used) then i'm having message objects instantly send on the neighbor.connect.success to update the others array of "online users"
So far it's working really well and i feel as if its a pretty effective system. But, I just wanted to ask how well it will scale and if it's worth continuing to develope or not because how well would it work if it had between 100-1000+ people. What is the max amount of neighbors? Will the object i have sending off when a neighbor connects to them cause an issue when it gets to be a bunch of clients all sending each other their username info on the neighbor connect event?
Another question would be if when 2 cleints decide to connect and say video/text chat i've been having them do a Direct Connection connect vi peerIDs and closing their netgroup connection so the disconnect event can delete the object with their peerID/username in it. Should I be leaving them connected as neighbors and use neighborids somehow? or should be be doing somethign where i have a pubish and play stream going at all times, but just have them pick a similar generated play/publish channel and them neigborsend that to each other? I just though If i have neighbors constantly disconnecting and doing direct connects it could help prevent the neighbor overload incase their is a limit.
It would be awesome if someone could help share some of their knowlege on these questions, thanks!

Answer 1

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.