This content has been marked as final. Show 7 replies
based on your description, here's what i think is going on:
i believe you have a NAT device with extremely short translation timeouts (less than one minute). so for a period of time, the peer introduction can't reach the intended destination because it has changed addresses but Stratus doesn't know that yet. within that one minute period, the destination Flash Player sends a keepalive packet to Stratus, which makes it notice the destination has a new address. at that time, the introduction packets from the initiator Flash Player can be delivered, and the peer-to-peer session can come up.
your second & further sessions won't have a delay because the low-level RTMFP peer-to-peer session already exists between them (it'll stay around for several minutes before being shut down if idle), and either 1) the peers are both behind the same NAT so their addresses don't change, or 2) peer-to-peer sessions have shorter keepalive periods, so the NAT translations are kept alive, or 3) you're re-trying before the NAT translation could time out.
does the up-to-a-minute delay happen if you try to make a peer-to-peer connection *right* after connecting to Stratus (within a few seconds)? both ends would need to connect to Stratus and a connection be attempted between them all within the span of a few seconds. if there is no up-to-a-minute delay, then my diagnosis is probably correct. if there is always that delay, even immediately after connecting to Stratus, then it might be something else, but we would need more information.
if possible, you should extend the translation timeout on your NAT to be no less than one minute.
Thanks for the extensive answer. I will have a more in depth look tomorrow. A quick answer to "... if you try to make a peer-to-peer connection *right* after connecting to Stratus (within a few seconds)?" though:
My initial code created the stratus connection just in time, closing it down after the session. In order to save time I moved the opening of the Stratus connection backward in time. So the initial design was doing exactly what you ask me to do now. Another reason to move the code wa to come closer to the Videophone sample app, which also separates the Connect from the Call in the same way.
I worked on this all day. Have a Linksys WRT54GS wireless router. As this doesn't have NAT config possibilities, replaced firmware by DD-WRT v23 SP2. This gives me Telnet access with VeryBusyBox v1.2.1 command set.
I couldn't find any NAT config possibility on the web interface, so I had to dive into command mode.
Now, this isn't obvious either, but I found in the directory /proc/sys/net/ipv4 the following files with content as below.
I have no idea how to work from here. Are you familiar with this?
/proc/sys/net/ipv4 # cat ip_conntrack_udp_timeouts
/proc/sys/net/ipv4 # cat ip_conntrack_tcp_timeouts
1800 3600 120 60 120 120 10 60 30 120
/proc/sys/net/ipv4 # cat tcp_fin_timeout
Furthermore the box supports many network related command like ifconfig, ip, iptables, etc, but I have no clue where to start.
By the way: I am pretty sure that my machines have very stable ip addresses, so if the problem would be that client ip adresses are constantly changing then I think we are on the wrong track. But may be NAT translation timeout is something different, I a mot an expert in this.
The other thing, about moving the NetConnection.connect closer to the peer stream publish and subscribe calls doesn't solve the problem, because this is what my first solution looked like. The reason to move the NetConnection.connect call to the beginning of the main program was just because I hoped this would give Stratus a bit more time for setting up, so that by the time the users press the connect button, Stratus would be ready with that process.
Anyway, I hope you can give me some hints how to proceed.
Investigated network traffic.
Discovered that delays happen only with initial publish/subscribe after NetConnection.connect.
Any further stopping and re-publishing and re-subscribing to streams (always using same stream name by-the-way) works instantaneously and only shows traffic between the peers, not with any Stratus server.
I captured and filtered relevant packets and filtered relevant application trace lines from flashlog.txt.
Hope this helps!
Congratulations, you found a bug in Stratus! :)
I have corrected the bug, and now it should work much better for you. Please give it a try and let us know.
This is really great! I can confirm that the delay has gone. Streams start immediately after connect now.
Happy to have been of help!
I have been reading a lot the last few days about NAT and related issues for peer-to-peer connectivity. Really great stuff and more complexity than I was aware of.
We will continue testing in various network configurations and report any further issues via this forum.
(can be removed; duplicate posting due to network issues)