the only way to know if there are others in a group is to join it and be bootstrapped into it. note that Cirrus' bootstrap service is that central service keeping track of the members of groups (that have the server channel enabled). if you made your own bootstrap service, you could query it for membership information, or (for your application) query some other kind of presence service to see if a friend was online before joining his group.
in addition to the 16 group limit on Cirrus, simply being in a group with at least one other member means you'll have 1-2kbps of background network traffic for that group. so if you're in 16 groups that each have at least one other member, that's 16-32kbps of background network traffic even if nothing else is going on. this is background traffic that every member will have.
if it was me, i would not structure my application like that.
thank you for your answer,
At first I wanted to have a full mesh where each friends connect to each other.
In this thread: http://forums.adobe.com/thread/751811?tstart=0 I explain my design but then zasdzasdzasd told me that it was clearly inefficient and it was better to use only one NetGroup for the whole application. Then after reading your answer to this thread: http://forums.adobe.com/thread/752581?tstart=0 I though it would be better to have as many group as there is friends.
Unfortunately as you say, it has an unecessary overhead sicne there is only few node in the groups.
I don't know then which method to use.
Should I use:
- one NetGroup for the whole application, meaning there could be thousands of member in this group which only less than 16 (around 4,5) would be interested in each message posted ?
- full mesh where each node send the information as many time as there is friend currently online (16 max?)
- one netgroup for each friend (too much overhead)
- or any other method?
I am just thinking of other possible solution:
- have one netgroup for the whole application, but each message are send as private message (through addNeighbour and sendToneighbour (executed as many time as there is friends online) ) but it seems to be like a full mesh without much advantage, isn't it?
- I could also use a netGroup for the whole application and make sure the routing mechanism give message to the sender friends. but unfortunately I do not want every node to know about other's friends.
Thank you for your help
If the message delivery latency is not critical you may also try to distribute one-to-few messages via object replication.
Artificially defined subgroups within the big group will listen to, acquire and redistribute a strict subset (defined by the centralized sever) of the 53bit object indexes.
This approach probably has the higher latency of all, yet should also be the most reliable. It's also transparent enough compared to manually adding extra neighbours.
Since the messages are sort of "persistent" among the subgroup you can add increased memory consumption to the downsides. This is more suitable for "message board" kind of messaging and if the persistance does not help your app you may want to no longer redistribute messages older than, say, 5 minutes.
the "subgroup" approach won't work with object replication. unless all members are trying to acquire the same set of objects, there isn't a guarantee that any peer will be able to acquire the desired set of objects. this is because the graph has full transitive connectivity but is not fully meshed (N:N). if your neighbors don't have or want the objects you want, you won't be able to get them.