3 Replies Latest reply on Dec 16, 2010 2:17 PM by jazz_matazz

    NOTICE: keepalive parameters changed, should reduce dropped connections

    Michael Thornburgh Adobe Employee

      more than one customer has complained about connections to Stratus dropping seemingly for no reason (spurious NetConnection.Connect.Closed).  we have determined a cause of at least some of these incidents.


      when Stratus thinks you are *not* connected through a NAT, it used to set your RTMFP keepalive time to 90 seconds.  however, even if you don't have a NAT, you might have a stateful firewall requiring UDP hole-punching.  some firewalls may time out the UDP holes in much less than 90 seconds.  it's possible that certain patterns of traffic (particularly when you use RTMFP Groups with the server channel for automatic group bootstrap) could cause data to be sent from the server after the UDP hole has timed out but soon enough that the ultiimate retransmission timeout will expire before the next keepalive re-opens the UDP hole.  in cases like this, the server will drop the connection, and eventually the client will detect that the connection has died and also drop (with the NetConnection.Connect.Closed event).


      once we determined the situation i described above, we decided to shorten the "not behind a NAT" keepalive period from 90 seconds to 20 seconds, which preliminary research has indicated should be sufficient (but hopefully not overkill).  for all new connections to Stratus, the servers command clients that are not behind NAT to use a keepalive time of 20 seconds.  since the keepalive packets are very small (20 bytes), the impact of this should be negligible (also, most people are behind NATs anyway, where the keepalive time was already 15 seconds).


      we hope that this change will reduce the number of spurious NetConnection.Connect.Closed events that people see.

        • 1. Re: NOTICE: keepalive parameters changed, should reduce dropped connections
          jazz_matazz Level 1



          I have got a little configuration question about this subject:

          In Adaptator.xm FMS4 configuration, we can choose a keepalive time for PEERS and SERVER.

          I understand the "peers keepalive value", each peer will send a keepalive packet in a corresponding interval, but What does it means a "keepalive server" connection? What is the role of its value?


          Thanks again for your job!

          • 2. Re: NOTICE: keepalive parameters changed, should reduce dropped connections
            Michael Thornburgh Adobe Employee

            both of these times are sent to a client when it connects, commanding it how to handle its different kinds of connections.


            the "server keepalive" parameter is the period a client's RTMFP session with the server must be idle before the client sends a keepalive ping.


            the "peers keepalive" parameter applies to each of the client's RTMFP sessions with its peers (if any).  for each of those sessions, if the session is idle for that long, the client will send a keepalive ping to that peer.


            the peers keepalive parameter is typically shorter than the server parameter for three reasons: servers are rarely behind NATs, while it's common for clients to be behind NATs, so P2P connections often need to try harder to keep translations alive; when using RTMFP, the whole point is P2P communication, so more effort should be focused on maintaining those connections; P2P keepalives are distributed while client-server keepalive can focus a lot of traffic in one expensive spot (the server/data center), so client-server keepalive packets should be kept at the minimum that still gets the job done (the "job" being: keep NAT/firewall translations/holes fresh and open, detect client IP address changes, detect connection loss).