3 Replies Latest reply on May 16, 2009 1:02 PM by Michael Thornburgh

    Checking for RTMFP failure due to a firewall


      When a firewall blocks UDP and hence RTMFP, I believe the NetStream.Connect.Closed event is fired on the NetConnection object after a 90 second timeout. For any application, it's important to detect this condition to alert the user of the problem, and advise him/her to allow UDP.


      Two questions:

      1. The same event is fired for a stream that's closed by normal usage (e.g. by a user closing the browser window). Is there a reason why a different event name is not used to help distinguish the 'bad' event from the 'good' one?


      2. It doesn't look like the 90 second period is configurable. Does it really take that long to try punching through the firewall, and realize it can't be done?


      I'd really appreciate any response. If there's a good way to detect a firewall issue, it would be very useful to all developers using RTMFP.

        • 1. Re: Checking for RTMFP failure due to a firewall
          Michael Thornburgh Adobe Employee

          1) when the other end closes the browser, there's barely enough time to send the abrupt session close messages on all RTMFP sessions, so there's definitely no time for the multiple round-trips that would be necessary to reliably transmit some kind of "i'm shutting down now" message, wait for acknowledgements, and then shut down the sessions.  at the end that's still running, the abrupt session close is indistinguishable at the RTMFP level from many other error conditions, including the "i never got a session up in the first place" case.  at the application level, you could certainly make a note of whether data had ever been received and change your interpretation of the NetStream close event.


          2) the 90 second timeout is not configurable, and is a worst-case try-really-hard period for trying to get communications working.  if your application doesn't need to try that hard, you can set a timer in ActionScript for a shorter time, and if it fires before you get connected you can abort.



          • 2. Re: Checking for RTMFP failure due to a firewall
            zhyder Level 1

            Thanks Mike, that makes sense. Regarding 2), do you have a sense for how long it would typically take to punch through most firewalls?

            • 3. Re: Checking for RTMFP failure due to a firewall
              Michael Thornburgh Adobe Employee

              given how RTMFP's UDP hole punching scheme works and under good conditions, it shouldn't take more than a few seconds to get through most firewalls/NATs if it's possible to do so.  if you are using a TURN proxy with Flash Player 10.0 or AIR 1.5, it could be up to 10-15 seconds.