Your load balancer can present a number of different strategies for choosing which
Diffusion™ server a new client connection is routed to. After a
client connection has been routed to a Diffusion server, ensure
that the client is always routed to the Diffusion server that its session
The routing strategies that are available to you depend on the load balancer that you
choose to use. The following table lists some examples of routing strategies:
Table 1. Examples of routing strategies
Each available Diffusion server is
chosen in turn, with none favored.
The Diffusion server with the fewest
number of client connections in progress is chosen.
The Diffusion server with the lowest
CPU load is chosen.
Routing connection that use HTTP
To route HTTP traffic, the load balancer must be
able to inspect the HTTP headers and extract
Diffusion sets an HTTP
cookie named session with a connection-specific ID specifically for
this purpose. Your load balancer can use this cookie to maintain a table of client
to server mappings.
The session cookie is flagged with HttpOnly, which prevents scripts
accessing the cookie. The session cookie is not flagged with
Secure, which prevents the cookie from being sent over non-secure
Diffusion uses a session ID for the cookie. This enables
the load balancer to maintain a map of each session ID to its target Diffusion
Instead, you can disable the Diffusion cookie and configure
the load balancer to set a cookie that identifies the target server instead of the
session. While the overhead of transmitting a cookie is still present between client
and load balancer, the identifier can be smaller because there are a smaller number
of servers than client sessions. Load balancers that use the cookie to identify the Diffusion server can send less data down the wire and consume fewer
If you want to configure your load balancer to inject its own cookie, you can disable
this Diffusion cookie. To disable the Diffusion cookie, set the
<disable-cookie> element in the
WebServer.xml configuration file of your Diffusion to true.
Routing connections that use streaming protocols
Streaming protocols that open a single
socket and remain connected until they are no longer required appear immune to
requiring any special routing considerations. However, in the event that connection
keep-alive is enabled to handle reconnections in case of temporary connection loss,
it is important that the reconnection attempt is routed to the original server.
Without the ability to parse headers (and indeed, the absence of a session ID at
all), the most common method for routing a streaming protocol such as WebSocket is
to create a client/server mapping based on the IP addresses of the endpoints. This
technique is generally referred to as Sticky-IP, and has the
advantage of also working with HTTP transports, if required.
For F5®'s Sticky IP, ensure that the Source Address
Translation option is set to Auto Map.
The drawback of this approach is that multiple users masquerading behind a proxy or
access point can have the same IP address, and all requests from clients with that
IP address are routed to the same Diffusion instance. Load
balancing still occurs, but some hosts might be unfairly loaded.