NetGroups and NetStreams exist within the context of a NetConnection. if the NetConnection is closed, then all NetStream and NetGroup objects associated with that NetConnection are closed.
RTMFP Groups are cooperative, distributed systems. all members of a group are equal and there are no special "master" or "control" peers, as far as the low-level group is concerned. if one member leaves (no matter which member), any other members will continue to be connected in the group.
there is no such thing as a "Stratus server" anymore. the service is now known as "Codename Cirrus".
Is there posibility to anyhow maintain NetGroup without NetConnection? For example if it's hacked flash player etc. Is NetConnection closing is reliable way to "disconnect" spammers/scammers/hackers etc. from the NetGroup or it's just a client side trigger, which tells to close Netgroups? For example if NetConnection instance won't be deleted after Cirrus disconnection, what will happen?
How NetGroups depends on NetConnection? NetConnection helps to get ip addresses of participants(nearrest Neighbors) right, after that flash player stores them and NetConnection is not required anymore to send messages?
having the NetGroup/NetStream objects close when their controlling NetConnection closes is just the behavior we defined for these ActionScript objects. someone who has hacked their Flash Player could disable this behavior, and someone who creates their own independent RTMFP implementation could not do that at all.
it is possible to join a NetGroup with a "serverless" NetConnection (one where you connect to "rtmfp:"), using IP multicast to bootstrap into the group with members on your LAN (assuming your group has ipMulticastMemberUpdatesEnabled=true and an IP multicast address associated with it). however, if you're in a group but not with a NetConnection that's connected to the server, the server won't know you're in the group and so can't direct new joiners to bootstrap to you. so at least one member of the connected group must remain connected to the server so new joiners can be bootstrapped in if they're not on the same LAN as other members of the connected group.
in addition to bootstrapping into the group, your connection to the server helps with NAT and firewall traversal and helps repair partitions that may occur in the group, perhaps as a result of a mass disconnection or Internet routing problems.
note that the server doesn't necessarily help peers with "nearest" neighbors. the Cirrus servers command new joiners to connect to a few other members of the group totally at random; the group's automatic distributed self-organization algorithm takes over after that bootstrap to settle new joiners into the group topology.
Woah how complex is everything.
A bit about "group's automatic distributed self-organization algorithm"
Ok, so basically each peer keeps the information about the local peers to help distribution.
So when hacker joined into the group and already got ip addresses of some peers it's impossible to remove him from the network?
It would be much easier if there could be some ability to insert some callback function before bootstraping new members of the netgroup and when message is routed via netgroup.post between peers.
For example hacker.post() -> peer(some application level ip or uuid server-side checking) -> stop
It's the same as Netgroup.sendtonearest routing functionality but with ip applied to event.
Why adobe haven't inserted such functionality into netgroup api, there is a reason for this?