i assume you're using the "server channel" to have the server bootstrap new members into the group?
depending on the NAT/firewall configurations of the existing members and the new joiner, the bootstrap candidates that Cirrus commands to the peers might not be able to make P2P connections. that will typically be the case when a large proportion of the peers are behind symmetric NATs or port/address restricted cone NATs.
NetGroup.sendToNearest()/.sendToNeighbor/.sendToAllNeighbors() should send the message immediately (but only to the specific or all directly connected neighbors, which might not be all members of the group -- to reach all members of the group, use NetGroup.post()). any delay between sending with sendToNearest()/sendToNeighbor/sendToAllNeighbors would be caused by packet loss/retransmission. messages sent with those methods are sent with full reliability, and will be retransmitted if they are lost.
the larger the group, the more likely it is that there will be enough peers with favorable NAT configurations to allow new members to join and for most group P2P modes to work. note that for sendToNearest() to work consistently (especially to build things like a DHT), the topology must be really correct. i talk about this more in my session from MAX 2011, which i recommend you watch:
http://tv.adobe.com/watch/max-2011-develop/advanced-p2p-with-rtmfp-tip s-and-tricks/
