SL4B provides connection failover functionality, allowing a client application that has lost its connection to a Liberator to failover and connect to another Liberator instead. It also provides client side load balancing, where each client randomly selects which primary Liberator it will initially attempt to connect to.
Prior to version 4.5 the connections specified in the XML defined not only the available connection types but also the order in which they would be tried on the server. In version 4.5 of SL4B the connections define the available RTTP methods (in no particular order) , the client uses this information to determine the best connection method for the current browser.
For example, if RTTP connection types 4 and 5 are defined in the XML then SL4B running in an IE browser will choose the 'HTML File' connection method which uses RTTP type5 as its preferred streaming connection, while Firefox will choose the 'XHR multipart' which uses RTTP type 4 for its connection.
Please see Connection Methods for more information.
To enable the failover functionality, the service
configuration attribute must be defined within the SL4B-enabled page. The value of this attribute should be
the URL of the an XML file that contains the details of the Liberators that make up the service and their
relationships with each other. SL4B uses the information from this file to decide which Liberator to connect
to initially, and to which Liberator it should failover to if it loses its connection to that Liberator, or
is unable to establish a connection.
In addition to the service configuration attribute the
commondomain attribute
must also be specified.
SL4B will failover if it loses its connection to the Liberator. It will not failover if the DataSource providing the data this client is subscribed to loses its connection
One common problem during failover occurs when SL4B reconnects to a Liberator that has recently restarted. The default configuration of a Liberator when it is starting up is to allow clients to connect even if the data service they wish to subscribe to is provided by a DataSource that is not yet connected. This results in the clients receiving "Not Available" messages and not being subscribed. This can be avoided by setting the 'required-state' attribute in the Liberator configuration for the data service to 'ok'. See the Liberator Admin guide for more information.
Please see Service Definition section for more information about the XML file and its format.
Caplin has designed a number of algorithms to select a backup Liberator from a list when a connection to a Liberator fails. These algorithms balance the load across the Liberators and minimise use of the backups. There are three algorithms, named after the pattern of selection they produce.
Note: The examples given below use two primary Liberators, with two backup Liberators. A1 is paired with backup Liberator B1, whilst A2 is paired with B2; the client is assumed to attempt to A1 first.
Always tries to failover to a primary Liberator. Backup Liberators will only be attempted if SL4B has failed to connect to all of the primary Liberators.
Example sequence: A1 > A2 > B1 > B2
If the client cannot connect to a primary Liberator, it attempts to connect to the backup Liberator. If there is no backup Liberator for the primary Liberator, then a Liberator is selected from the list of other backup Liberators.
If the client cannot connect to the backup Liberator, then it will attempt to connect to another backup Liberator. It should only attempt to connect back to a primary Liberator once the list of backup Liberators has been exhausted.
Example sequence: A1 > B1 > B2 > A2
If the client cannot connect to a primary Liberator, it attempts to connect to the backup Liberator. If there is no backup Liberator for the primary Liberator the client is connected to, then a Liberator is selected from the list of primary Liberators.
If the client cannot connect to the backup Liberator, then it should attempt to connect to a primary Liberator.
Example sequence: A1 > B1 > A2 > B2
Client applications must download an XML file to use algorithm-based failover. This XML file
must have the content type of text/xml.
The XML file must contain a list of Liberators available for the RTTP Service (a set of Caplin Liberators which all accept
the same clients and provide the same set of data), and the preferred failover algorithm defined in a
<failoveralgorithm> element.
If no XML file is specified, the serverurl attribute will be used to determine which Liberator to connect to.
A document type definition (DTD), which specifies the required format of the XML file, can be found in the
htdocs directory of the Liberator installation (.../htdocs/service/rttpservice.dtd). It is recommended that
this file is copied to the same directory as the XML file.
The elements that can be used to define which Liberators are available to connect to, and the types of connections can be used to connect are defined in the following table.
| Element | Description |
|---|---|
rttpservice |
Defines the RTTP site(s) that make up the RTTP service. It may contain the name describing the service, and/or a failoveralgorithm. It must contain an rttpsite. |
rttpsite |
Defines the Liberators that are available. It may contain the name for the site. It must contain either a primaryserver or a serverpair. Beyond this, it may contain any number of primaryservers, backupservers or serverpairs. |
serverpair |
Defines both the primaryserver and the backupserver that make up the failover pair. It is illegal to define a
serverpair without both a primaryserver and a backupserver. If a primaryserver and/or a
backupserver need to be added without a failover pair, then they should be added directly as a child of the rttpsite. |
primaryserver |
Defines the details of the Liberator. It must contain the address of the Liberator. It may contain the name of the Liberator, the ports used to connect to the Liberator, and/or the weight to apply to the Liberator during failover. It must also contain the types of connections that should be attempted. |
backupserver |
As primaryserver. |
failoveralgorithm |
Defines which failover algorithm should be used by the client (Z, U or N) to failover between Liberators. |
name |
Defines a name to be displayed to the user for the rttpservice, rttpsite, primaryserver or backupserver. |
address |
Defines the location of the Liberator. This should not include the http/https prefix (e.g. secure1.caplin.com). |
weight |
Defines the weighting that should be applied to the Liberator when the client decides which one to connect/failover to. This value should be an integer. If this is not specified, then a default value of 1 will be used. Any non-integer values, or values less than 1, will cause an exception to be thrown. |
connections |
Defines the types of connections to be used to attempt to connect to the Liberator. These can be type3 (refresh) or type5 (streaming JavaScript), and the order they are listed in will be the order the connections are attempted in. At least one connection type must be included. |
type2 |
Defines that the Liberator supports RTTP type2 connections (XHR Streaming). The value defines whether this should be attempted over http or https. If the value is not http or https, an exception is thrown. |
type3 |
Defines that the Liberator supports RTTP type3 connections (Polling). The value defines whether this should be attempted over http or https. If the value is not http or https, an exception is thrown. |
type4 |
Defines that the Liberator supports RTTP type4 connections (XHR multipart). The value defines whether this should be attempted over http or https. If the value is not http or https, an exception is thrown. |
type5 |
Defines that the Liberator supports RTTP type5 connections (Javascript streaming, used for Forever Frame and HTML File connection methods). The value defines whether this should be attempted over http or https. If the value is not http or https, an exception is thrown. |
ports |
Defines which ports should be used to connect to the Liberator. It may contain a http, a https tag, and a direct tag. |
http |
Defines the port to be used to make an http connection to the Liberator. This value should be an integer. If the value is not an integer, or is less than 1, an exception is thrown. The default value of 80 should be used if this tag is omitted. |
https |
Defines the port to be used to make an https connection to the Liberator. This value should be in integer, if not, or if the value is less than 1, an exception is thrown. If the tag is omitted, the default value of 443 should be used. |
An example XML file is given below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rttpservice SYSTEM "http://www.example.com/SL4B/rttpservice.dtd">
<rttpservice>
<!-- optional name for the service -->
<name>Example RTTP Service</name>
<!-- optional specification of the failover algorithm to use; if this is
included the client cannot override it -->
<failoveralgorithm>U</failoveralgorithm>
<!-- definition of the Liberators that make up this service -->
<rttpsite>
<!-- first primary/backup Liberator pair -->
<serverpair>
<!-- primary Liberator -->
<primaryserver>
<address>primary1.example.com</address>
<!-- Liberator supports RTTP type 5 (streaming JavaScript) and RTTP type 3 (Polling)
connections over http (using the default http port, 80)-->
<connections>
<type5>http</type5>
<type3>http</type3>
</connections>
</primaryserver>
<!-- backup Liberator -->
<backupserver>
<address>backup1.example.com</address>
<!-- Liberator supports RTTP type 5 (streaming JavaScript)
connection (using the default https port, 443) -->
<connections>
<type5>https</type5>
</connections>
</backupserver>
</serverpair>
<!-- second primary/backup Liberator pair -->
<serverpair>
<!-- primary server -->
<primaryserver>
<address>primary2.example.com</address>
<!-- Liberator supports RTTP type 5 (streaming JavaScript) using https and RTTP type 3 (Polling)
using http -->
<connections>
<type3>http</type3>
<type5>https</type5>
</connections>
<ports>
<http>88</http>
<https>43</https>
</ports>
<!-- give weighting of 2 to this Liberator, when the client first
attempts to connect it uses the Liberator weighting to
determine which Liberator to connect to; a Liberator with a
weight of 2 is twice as likely to be selected as a Liberator
with a weight of 1 (the default weight) -->
<weight>2</weight>
</primaryserver>
<!-- backup Liberator -->
<backupserver>
<address>backup2.example.com</address>
<!-- connection behaviour identical to primary1.example.com -->
<connections>
<type5>http</type5>
<type3>http</type3>
</connections>
</backupserver>
</serverpair>
</rttpsite>
</rttpservice> |