Support for External Hardware Load Balancers in TCP Transport Plugin
For two Connext DDS applications to communicate, the TCP Transport Plugin needs to establish 4-6 connections between the two communicating applications. The plugin uses these connections to exchange DDS data (discovery or user data) and TCP Transport Plugin control messages.
With the default configuration, the TCP Transport Plugin does not support external load balancers. This is because external load balancers do not forward the traffic to a unique TCP Transport Plugin server, but they divide the connections among multiple servers. Because of this behavior, when an application running a TCP Transport Plugin client tries to establish all the connections to an application running a TCP Transport Plugin server, the server may not receive all the required connections.
In order to support external load balancers, the TCP Transport Plugin provides a session-ID negotiation feature. When session-ID negotiation is enabled (by setting the negotiate_session_id property to true), the TCP Transport Plugin will perform the negotiation depicted in Figure: Session-ID Negotiation.
Figure: Session-ID Negotiation
During the session-ID negotiation, the TCP Transport Plugin exchanges three types of messages:
Session-ID Request: This message is sent from the client to the server. The server must respond with a session-ID response.
Session-ID Response: This message is sent from the server to the client as a response to a session-ID request. The client will store the session ID contained in this message.
Session-ID Indication: This message is sent from the client to the server; it does not require a response from the server.
The negotiation consists of the following steps:
- The TCP client sends a session-ID request with the session ID set to zero.
- The TCP server sends back a session-ID response with the session ID set to zero.
- The external load balancer modifies the session-ID response, setting the session ID with a value that is meaningful to the load balancer and identifies the session.
- The TCP client receives the session-ID response and stores the received session ID.
- For each new connection, the TCP client sends a session-ID indication containing the stored session ID. This will allow the load balancer to redirect to the same server all the connections with the same session ID.
Session-ID Messages
TCP Payload for Session-ID Message depicts the TCP payload of a session-ID message. The payload consists of 48 bytes. In particular, your load balancer needs to read/modify the following two fields:
CTRLTYPE: This field allows a load balancer to identify session-ID messages. Its value (two bytes) varies according to the session-ID message type: 0x0c05 for a request, 0x0d05 for a response, or 0x0c15 for an indication.
SESSION-ID: This field consists of 16 bytes that the load balancer can freely modify according to its requirements.
|
00 |
01 |
02 |
03 |
04 |
05 |
06 |
07 |
08 |
09 |
10 |
11 |
12 |
13 |
14 |
15 |
|
RTI reserved |
0xDD |
0x54 |
0xDD |
0x55 |
CTRLTYPE |
RTI reserved |
|||||||||
|
|
|||||||||||||||
|
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
|
RTI reserved |
|||||||||||||||
|
|
|||||||||||||||
|
32 |
33 |
34 |
35 |
36 |
37 |
38 |
39 |
40 |
41 |
42 |
43 |
44 |
45 |
46 |
47 |
|
SESSION-ID |
|||||||||||||||
To ensure all the TCP connections within the same session are directed to the same server, you must configure your load balancer to perform the two following actions:
Modify the SESSION-ID field in the session-id response with a value that identifies the session within the load balancer.
Make the load-balancing decision according to the value of the SESSION-ID field in the session-ID indication.
© 2018 RTI