3 Replies Latest reply on Jul 21, 2012 1:32 PM by Michael Thornburgh

    Checking if user is behind the firewall on client-side.

    Somebbb

      Before connecting anywhere, i want to check if user firewall isn't blocking our connections.

       

      Is that possible anyhow?

        • 1. Re: Checking if user is behind the firewall on client-side.
          sh4nx0r

          "Before connecting" ,  I don't know if that's possible.

           

          But you can use NetConnection object to achieve this.

          You will get a "NetConnection.Connect.Failed" event when Firewall is enabled. So you could alert the end-user with this.

          • 2. Re: Checking if user is behind the firewall on client-side.
            Somebbb Level 1

            I know it, but the problem is, that i will get NetConnection.Connect.Failed after 30+ seconds right? When flash player will reach it's timeout threshhold right? Is it possible to avoid waiting for 30+ seconds and check that right away, by some kind of ports analysis of etc?

            • 3. Re: Checking if user is behind the firewall on client-side.
              Michael Thornburgh Adobe Employee

              the only way to know for sure whether RTMFP will work is to try.

               

              you might be behind a NAT or firewall that could allow a connection to Cirrus but that would block most P2P connections.  or you might be behind a firewall that blocks UDP altogether, so you couldn't connect to Cirrus at all.

               

              "connecting to Cirrus" pretty much means "UDP to ports 1935 and 10000-10100 works".  any other UDP connectivity test on some other port would be be similar except it wouldn't tell you about the ports you really care about, and testing it would probably take about the same amount of time to be sure.

               

              you can always set a timer to give up earlier than the RTMFP connection timeout time.  for example, if you don't get an RTMFP connection in 5ish seconds, you could bring up an RTMP connection to AMS, while continuing to try the RTMFP connection.  if the RTMFP connection eventually succeeds, you can preferentially use it (or switch to it), but if it doesn't come up, at least you'll have built your fall-back channel sooner rather than later.

               

              if you're having RTMFP connectivity problems, take a look at the RTMFP Connectivity Checker diagnostic tools:

               

                http://cc.rtmfp.net/  (IPv4)

                http://www.rtmfp.net/cc6/  (IPv6)