Skip to main content
T
teel_
Known Participant
October 15, 2009
Question

Connecting takes a long time

  • October 15, 2009
  • 1 reply
  • 2090 views

For some reason connecting to Flash Media Server 3.5 takes around 40 seconds. The server is running on Windows Server 2008 (64-bit edition) on a virtual server located in a reliable hosting center and I'm connecting to it over the internet. The server is using built-in Windows Firewall with all the inbound TCP ports required by Flash Media Server opened (80, 1935 and 1111). If I disable the server's firewall the connection time drops to 20 seconds, but it's still pretty damn long time just for establishing connection. We probably have some company firewall at this end (the client side), but other streaming media services works just fine over this connection.

Any suggestions? I was under the impression that the connection should be practically instant (practically meaning that the user shouldn't have to wait for it).

    This topic has been closed for replies.

    1 reply

    A
    Anonymous
    October 15, 2009

    When you're connecting, are you explicitly defining the port to use, or are you letting the flashplayer use its default behavior for connecting? From your description, my first suspicion is that port 1935 is blocked somewhere (perhaps there's another firewall between your server and the internet.

    Try making an explicit connection over port 1935:

    nc.connect("rtmp://myserver.com:1935/myapplication");

    If the connection outright fails, then test port 80

    nc.connect("rtmp://myserver.com:80/myapplication");

    If 1935 fails and 80 connects right away, the problem is that 1935 is blocked somewhere.

    T
    teel_Author
    Known Participant
    October 16, 2009

    Thanks. I tried the service from my home computer (where I can be sure which ports are blocked and which are not) and the connection was established in less than a second so at least it should be ok on the server's side.

    I had not defined the port explicitly, so I was relying on Flash Player's default behaviour. I tried defining in explicitly now, but there's no change. I also tried connecting directly to port 80 without success.

    Should I configure the server so that the RTMP port is some common port that should be always open (like 80) everywhere? Or might that cause other problems on the user's end?

    Also I'm not exactly an expert on these matters so correct me if I'm wrong. Does Flash Player use RTMP HTTP tunneling by default as a fallback if the connection to the RTMP port 1935 fails? If so, can I adjust how long the connection is attempted before falling back to HTTP tunneling? I'm guessing that's at least part of the reason for the long delay.

    A
    Anonymous
    October 16, 2009

    You have it right, the flashplayer will fall back on RTMPT:80 if it can't make an RTMP connection. If you let the flashplayer use it's default behavior, I find it takes about 20 seconds for each protocol/port combination to time out. Unfortunately, there's no access to that timeout value through the actionscript API.

    A lot of developers like to use the "shotgun" method of connecting, where separate netconnections are create for each port:protocol combination and connected to at once. The first one to receive a success status becomes the winner (the connection that will actually be used), and the rest are closed and discarded.

    Another option is to try your preferred port:protocol combinations in sequence, and use a Timer() to set your own timeout for each, each combination in succession. I personally prefer this method, as it reduces the number of handlshakes and connect requests the server has to handle (I'll trad a few seconds of wait time on the client side to save load on the server any day).

    One thing to keep in mind, Mac OS may give you problems if you make your timeout too short. You can read more about that here:

    http://blog.jaycharles.net/?p=47

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices