Resilience in StreamLink

StreamLink supports highly resilient operation by providing the ability to connect to alternative Liberator servers (failover) and by trying alternative types of RTTP connection. These capabilities are defined through configuration, which is defined below. For a high level overview of failover within the Caplin Platform, see here.

Configurable failover strategy

When a client’s connection to a Liberator server fails (either because there is a persistent network failure or because the Liberator has failed), the client can connect to an alternative server according to a configurable failover scheme. StreamLink also uses this scheme when it first connects the client to a server. The configuration technique is flexible and allows you to define sophisticated failover schemes. Liberator servers can be collected into 'ordered' groups which are nested within a 'balance' group.

  • 'ordered' group: on first connection or during failover, StreamLink tries each of the servers or groups in an 'ordered' group in turn, in the order they have been declared within the configuration.

  • 'balance' group: the 'ordered' groups within a 'balance' group are tried at random.

Example failover configuration (JSON syntax):

[
 ["rttp://primary1.example.com", "rttp://backup1.example.com"],
 ["rttp://primary2.example.com", "rttp://backup2.example.com"]
]

This configuration defines two 'ordered' groups (the first and second inner arrays) within an outer 'balance' group (the outer array). This means that when StreamLink first tries to connect to a server, it randomly chooses between "1st group" and "2nd group".

Each 'order' group defines a primary server ("primaryN.example.com") and a backup server ("backupN.example.com"). Within the selected group StreamLink first attempts to connect to the primary server; if this fails, it attempts to connect to the backup server. If neither server can be reached, StreamLink attempts to connect to the servers in the other group.

So the servers are tried in one of the sequences below:

  • primary1 > backup1 > primary2 > backup2

  • primary2 > backup2 > primary1 > backup1

In a failover scenario, StreamLink first attempts to reconnect to the next server in the current 'order' group, followed by the servers in the other 'order' group. Once all possible connections have been tried, repeats the sequence of connection attempts after the configured reconnect delay.

Load balancing

'Balance' groups in the configuration allow you to implement server load balancing. If there are several servers (or server groups) within a 'balance' group, each client connects at random to one of the servers, so when there are many connected clients, the connections are distributed fairly evenly across the available servers. A configuration that implements server load balancing would look like this:

Server load balancing configuration (JSON syntax)
[
 ["rttp://liberator1.example.com"],
 ["rttp://liberator2.example.com"],
 ["rttp://liberator3.example.com"],
 ["rttp://liberator4.example.com"]
]

Alternative RTTP connection types

When a client attempts to connect to a Liberator, StreamLink refers to an ordered list of RTTP connection types . It tries each type of connection in sequence until one succeeds. If none of them succeed, StreamLink tries to connect to another Liberator, according to the configured failover scheme.

By default, StreamLink tries to connect via its default connection types, as defined by the browser or particular StreamLink technology. However, you can explicitly configure the connection types to try, as shown in the following example.

Configuration defining connection types (JSON syntax)
[
 ["rttp://liberator1.example.com"],
 ["poll://liberator2.example.com",
  "http://liberator2.example.com",
  "ws://liberator2.example.com"]
]

The example shows that StreamLink is configured to connect to liberator1 using the default StreamLink connection types; the configuration specifies this using the generic connection type rttp. In contrast, when StreamLink attempts to connect to liberator 2, it first tries a Polling connection (poll), then an HTTP Streaming connection (http), and finally a WebSocket connection (ws).