The Tokio Runtime For Rust: Part II, Redis.

Photo by Michał Mancewicz on Unsplash

Greetings, Ladies and Gentlemen! In one of our previous publications entitled “The Tokio Runtime For Rust: Part I, WebSocket.”, we provided detailed discussions about the Tokio, the de facto asynchronous runtime for developing ultra-low-latency Rust applications. One of the important factors that we consider when choosing the foundational layer (in this case a Rust asynchronous runtime) for our own work is to examine its ecosystem. Tokio’s ecosystem is very mature. Redis, Kafka, ZeroMQ, Postgres, InfluxDB… Almost any backend system that we can think about have native support for the Tokio runtime, which will allow them to be seamlessly integrated into a trading system built upon Tokio. However, it is NOT a no-brainer task to achieve ultra-low latency for high frequency trading applications. Special care must be taken. Sometimes even seasoned Rust programmers might overlook some important details which can throw big surprises when low latency is most needed. In this article, we will discuss one such detail called “Nagle Algorithm”.

So what is “Nagle Algorithm”? And how it can affect latency in high frequency trading systems? When an application sends many small chunks of data, Nagle algorithm holds back outgoing packets until either the previous unacknowledged packet is ACK’d or enough data has accumulated to fill a full-sized packet. This reduces the number of tiny packets flooding the network (sometimes called the “small packet problem”). The tradeoff is added latency. By default, Nagle algorithm is enabled. This is the case for all libraries in all programming languages. Nagle algorithm is enabled by default in the TCP specification (RFC 896)!

Now let us see how it can quietly come into play in a high frequency trading system and silently affect latency in a very randomized manner. A common setup for a trading system is that there is a market data listener that would connect to various exchange’s WebSocket API. Upon receiving a WebSocket message from the exchange, it will send it downstream to a central pub-sub system so that all other components can consume that data. A very popular and very standard low latency choice for such a central pub-sub system is Redis which provides Redis stream for pub-sub capability. XADD is the Redis command used to append entries to a Redis stream. XADD commands in Redis are often very small on the wire — around ~150 bytes for a typical command. Ethernet Maximum Transmission Unit (MTU) is usually ~1500 bytes, so a single XADD packet is far below the maximum payload size that TCP could send in one segment. So if your app does: XADD, XADD, XADD very quickly, the operating system kernel may hold writes briefly in a buffer without actually sending them out, hoping to combine them into one larger TCP segment. This “brief hold” is the Nagle Algorithm! Think of XADD like shipping boxes. If the postal office starts to quickly receive a lot of small shipping boxes all sharing the same destination, it has a good reason to wait a little bit so as to combine them onto the same delivery truck. It certainly greatly improves efficiencies but obviously adds small delays. Coincidentally, the command to disable Nagle Algorithm in almost any programming languages is generally called set_nodelay . 😂

Does that delay exist in the client library that you use? It all depends on the authors of the source code. For example, when the authors of https://github.com/redis-rs/redis-rs writes the code by using the Tokio runtime, they have the absolute freedom to choose whether to enable it or disable it. The underlying Tokio runtime’s default behavior is to leave Nagle Algorithm on as the TCP specification said but provides the option to turn it off if needed: https://github.com/tokio-rs/tokio/blob/tokio-1.52.3/tokio/src/net/tcp/stream.rs#L1179. The user has the final authority to make the decision. If your team is developing a high frequency trading system and do not explicitly turn off the Nagle Algorithm, there is a good chance that your system’s latency will jitter due to Nagle Algorithm (and potentially many other factors).

Nagle Algorithm is just one of many small things that a seasoned developer might overlook and results in an undesired latency introduction. If you worry about these “small” things which quickly add up in your system, we are here to provide end-to-end development services for trading infrastructures, covering everything from integration and strategy implementation to real-time data handling and execution. As you already saw, we pay great attention to details! 🎉