Real time communications over UDP protocol

Introduction 

Fast and reliable communications is a basic requirement in almost all modern applications, but the real time systems take it to extreme and require real time responses from the network. In some cases, the requirements are so tough that may require special hardware to achieve desired performance. During the last decade, new technologies have emerged to support the growing demand, but their prices are high and availability is low. As a result, most of the systems are still using TCP/IP protocols stack over Ethernet backbone. Moreover, most of the programmers are still developing with well-known synchronous sockets API. This article explores usage of these dominating technologies in the real time systems and shows how to design and develop communications within such systems. In particular, it proposes reliable protocol over UDP transport layer, that gains less than one millisecond average round trip time (RTT) and processes dozens of thousands of messages every second at each and every port in network. 

Background 

Real time networking is a non-easy task, so before move any further, system connectivity requirements must be analyzed. The right way to do it is to map and classify traffic in the system. First classification to be made is messages sizes and their latency requirements. In many cases, these two parameters are sufficient to choose transport protocols and network topology.

Let us start with the transport protocol choice. Since this article concentrates on TCP/IP, our choice will be between TCP and UDP. The table below proposes protocol selection rules:

There is a question sign in low latency and large messages cell in the table above. In this specific case, we should consider different approaches, such as RDMA over Infiniband™, but these technologies are not in scope of this article.
TCP

Long messages may contain database tables, pictures, videos, bunches of parameters and other types of data which must be moved around the system without compromising its performance. The TCP protocol is dealing quite well with big amounts of data. Long messages allow TCP to warm up its engines and find best fit for sliding window to avoid retransmits and achieve good utilization of bandwidth. But as latency requirement become tighter, the TCP protocol exposers its weaknesses.

First, the TCP latency is not deterministic. Consider server with multiples clients. Clients are sharing the same link and thus their traffics affect each other latency. Given the fact that the TCP protocol is lacking fairness and quality of service features, the latency variation may exceed hundreds of milliseconds. Moreover, in case of multiple clients, the bandwidth utilization may significantly drop down (in legacy systems it may collapse to 50%).

Another problem that TCP suffers from is slow recovery process. Regular recovery for a lost TCP fragment may take hundreds of milliseconds. There are some tricks which allow reducing recovery time. For example, in Windows XP™, configuring of TcpAckFrequency and TcpDelAckTicks parameters in registry achieve 200ms saving in recovery time. Unfortunately, these settings are not available in all operating systems and even if they were, there are other TCP timers and algorithms which keep the recovery time high.

Short messages are special challenge for the TCP. By default, TCP uses Nagle algorithm to accumulate short messages and send them together. The algorithm may delay packets sending and, thus, affect their latency. Sockets provide an API to disable this behavior (see setsockopt function documentation), but legacy sockets implementations may not have this functionality.

Concluding the above, TCP is a great protocol, but it is not suitable for real time communications. As it has been stated in the table 1, it could be successfully used only in systems with latency above hundreds of milliseconds.

Read more: Codeproject
QR:

Posted via email from Jasper-net