In order to prevent excessive simultaneous requests to provisioning and stream servers, the player must implement a “reasonable” connection management scheme. The basic idea is to use an exponential back-off retry scheme when attempting reconnections, where the player doubles its retry delay at every attempt, up to a certain limit. An element of randomness is added to spread the load from connection attempts over time.
The worst-case scenario is when a large number (e.g., thousands) of players disconnect simultaneously from a server (e.g., due to a server crash or network conditions). This algorithm is designed to prevent a large number of clients from attempting to fetch provisioning information or connect to a stream at the exact same time.
The reconnection algorithm should be implemented using the process shown below. (The player breaks out of this loop as soon as a valid connection is established.)
Implementing the reconnection algorithm:
- Initially set the retry delay to a random number from 1 to 5 seconds.
- Fetch the stream’s configuration via the provisioning API described previously.
- If the provisioning request fails, double the retry delay (up to a maximum of 1 minute), wait for that delay, then try the provisioning request again (i.e., jump back to step 2). Do this until provisioning information is received.
- Attempt connection to the first server in the list, using the first port.
- If the connection is refused, try the next port. Repeat until all ports for this server have been attempted. This is done to attempt non-standard ports in case the player is behind a strict firewall.
- If the end of the server list is reached, the player should double the retry delay (up to a maximum of 1 minute), then re-fetch the provisioning information with a new request (i.e., jump back to step 2).
Visually, the process can be represented as follows:
