TCP scalability improvements Reply

I’m excited to talk about new stuff we have added to our latest release, RTI Connext 5.2.0. In particular, I’ll talk about scalability improvements we added to the RTI TCP Transport Plugin.

Full Windows IOCP Support

RTI Connext can be used for a wide range of scenarios: from relatively small deployments with dozens of DomainParticipants communicating over a LAN, to WAN scenarios involving hundreds or even thousands of DomainParticipants. Our TCP transport provides a way to communicate over the WAN that is NAT-friendly and easy to configure. In WAN scenarios, the transport can be used in asymmetric mode. In this case, there is one DomainParticipant acting as a TCP server that receives connections from several other DomainParticipants acting as TCP clients. The server DomainParticipant does not need to know the addresses of the client DomainParticipants.

Something to consider when building a TCP server that handles hundreds or thousands of clients is socket management strategy, or socket monitoring strategy. This refers to how the system reacts to socket-generated I/O events.

While the strategy used by RTI Connext 5.0.0 TCP Transport Plugin (select() monitoring) had good scalability for servers running on Linux systems (up to 1,500 clients), we observed during experiments that scalability on Windows systems dropped to approximately 600 clients.

In order to solve this issue, RTI Connext 5.1.0 added partial support of MS Windows IOCP (I/O Completion Ports) socket monitoring strategy to the TCP Transport Plugin.

MS Windows IOCP provides an efficient threading model for processing multiple asynchronous I/O requests on a multiprocessor system. During our test on Windows systems running RTI TCP Transport Plugin, we observed an increase of the scalability from roughly 600 clients to 1500. However, RTI Connext 5.1.0 did not include Windows IOCP support for TLS over TCP.

I’m glad to announce that the latest release RTI Connext 5.2.0 includes full support of Windows IOCP socket monitoring strategy.

You can start using this feature by adding the following XML snippet to the TCP Transport Plugin configuration:

<participant_qos>
  <property>
    <value>
      <element>
        <name>{transport_prefix}.socket_monitoring_kind</name>
        <value>WINDOWS_IOCP</value>
      </element>
    </value>
  </property>
</participant_qos>
  • *Where {transport_prefix} is the name you assigned to the RTI TCP Transport Plugin (for example, dds.transport.TCPv4.tcp1).

External Load Balancer Support

Windows IOCP support is not the only new scalability improvement included in RTI Connext 5.2.0. Now I’ll talk about another addition that provides support for even more DomainParticipants acting as TCP clients.

When requiring high scalability using TCP, the TCP server becomes the bottleneck, and we need to take advantage of external load balancers. A load balancer is a software or hardware device that increases the capacity and/or reliability of a system by transparently distributing the workload among multiple servers. In particular, a TCP load balancer distributes connections from TCP clients among multiple TCP servers – in our scenario, DomainParticipants.

RTI Connext TCP Transport Plugin creates multiple connections when communicating two DDS DomainParticipants. These connections create a common state – a session – between the two DomainParticipants. In previous releases, the RTI TCP Transport Plugin was not friendly with externals load balancers. This was because a load balancer may have distributed the connections among multiple DomainParticipants , thus preventing communication.

diagram00

In order to support external load balancers, RTI Connext 5.2.0 includes a new session-id negotiation feature. When session-id negotiation is enabled (by using the negotiate_session_id property) the TCP Transport Plugin will perform an additional message exchange that allows load balancers to assign to the same DomainParticipant all the connections belonging to the same session:

diagram01

In order to enable the session-id negotiation, you can use the following XML snippet:

<participant_qos>
  <property>
    <value>
      <element>
        <name>{transport_prefix}.negotiate_session_id</name>
        <value>1</value>
      </element>
    </value>
  </property>
</participant_qos>
  • *Where {transport_prefix} is the name you assigned to the RTI TCP Transport Plugin (for example, dds.transport.TCPv4.tcp1).

This feature has been tested on a system using F5 Big-IP load balancer. However, it will work with other load balancers as long as:

  • They are able to modify the TCP data stream to include a unique identification of the node serving the first connection on a session.
  • They are able to assign connections to a server depending on the content of the TCP data stream.

I hope you find these new features useful and helpful in deploying highly scalable RTI Connext–based systems. To try it for yourself, download our free 30 day trial, today!

Submit a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s