I also had a problem recognizing new naighbours,
but could speed it up by posting a lot of messages from each user.
I also have set
gs.multicastEnabled = true;
But sending messages and streaming audio still laggs a lot for me.
Streaming audio laggs with 2-3 seconds.
And messages with 0.5 sek.
This is trying on my own computer with two browser windows.
I'm behind a firewall, but don't know if that matters as I'm getting through,
but it's just slow.
the initial connection to Stratus shouldn't take 2-3 seconds to come up in normal circumstances. the worst case *should* be four round-trip times to our data center before you get NetConnection.Connect.Success.
possible explanations for a delay like that include being about 90,000 miles away from Los Angeles, California, USA, Earth (unlikely), or having a heavily congested network path between you and Los Angeles, or a network path with considerable packet loss, or you are using a TURN proxy. certain fussy firewalls may fight with the aggressive parallel-open technique RTMFP uses to establish connections, which could cause session startup delays (or occasionally causes sessions to not start at all).
large round-trip times or heavy congestion or packet loss between you and Stratus could also account for difficulty in establishing P2P connections -- especially the first bootstrap connections to a group. members of groups gossip amongst themselves about other members and automatically make new connections using as much locally-derived information as possible before asking for help from the server (Stratus). that can explain a large delay for getting the first NetGroup.Neighbor.Connect, but then a rapid flurry of new neighbors shortly after that (once the members can start gossiping about each other).
finally, the logging output you included shows "Attempting connection to stratus://83e81d742a65f91695xxxxxx-xxxxxxxxxxxx". i assume you're not trying to use "stratus://83e81d742a65f91695xxxxxx-xxxxxxxxxxxx" as the NetConnection.connect() URI, but actually "rtmfp://stratus.adobe.com/83e81d742a65f91695xxxxxx-xxxxxxxxxxxx", since the former shouldn't work at all.
posting messages won't speed up neighbor connections.
streaming audio/video in a group (multicast) is expected to lag by several seconds with the default settings. postings are expected to have a .25 to .5 second delay.
I think I found the timing issue in creating the connection to the bootstrap server -- I was using a callLater() function to create it, and there was something chewing up the frame's thread for a moment.
In my lab that I've been testing with, we have a single firewall (NetScreen 25GT), while attempting for the bootstrap server to find three machines behiend this firewall, which is acting as a NAT. There are no rules in place that should be blocking the traffic (and the firewall is not reporting that it is blocking anything, but I wouldn't take that as gospel). The three machines we are testing with are a Windows 7, Mac OSX 10.6, and a Windows XP SP3 (all running the same AIR 2 runtime)
What we have found is if we are creating a new group, it takes forever, but if that group is already functioning, most of the clients connect fairly quickly (although the Mac client still can take 30+ seconds). We see this most often in our testing because we will create an .AIR file, deploy on our lab, and run them nearly at the same time.
You are correct in the stratus:// in the log file... we are actually connecting to the Adobe Stratus server (we store this in a var, in hopes that one day we will be able to use our internal FMS server to bootstrap the clients).
Thanks for the help!