Better delivery transport for streaming market data over the internet

Gurpreet Bal
Platform Application Developer Platform Application Developer

Streaming stock prices - also called market data in the industry speak, is a core component of many financial application. Any trading activity happening at a stock exchange, makes its way to the end user through a series of infrastructure components. These components are:

  • A matching engine at the exchange, where the orderbook is maintained. Inserts/updates to the order book show up as Quote messages, and the top of the book matches are the Trade messages.
  • This quote/trade/orderbook data is disseminated by the exchange to data vendors like Refinitiv, where the data is processed, value added with fundamental data, cleaned - corrections and trade conditions etc are applied.
  • For the cloud consumers - this real time data stream is disseminated to the user applications through the streaming channels.

In this discussion, I will talk about the last leg - i.e. data distribution to user applications over the public internet cloud. Currently, this data distribution from Refinitiv, is either over a propriety compressed binary protocol called RWF, or a text based JSON protocol. Both of these protocols deliver data to a user applications over the TCP connection.

At the backend (exchange level), this low latency and high throughput delivery is highly tuned, and invariably uses a redundant UDP multicast channels for delivery. On the front end (to user applications) however, a TCP stream is used. Few vendors like Refinitiv, used to provide an option for multicast delivery. This used to be an option for delivery to user application, when the market data delivery infrastructure components, and the user applications resided in the same data center, and possibly shared the same subnet. Later, advances in networking hardware made the TCP delivery channels faster and easier to use, and this multicast delivery fell out of favor. For the cloud delivery over the internet however, TCP based WebSockets protocol is the only available approach. This is already a huge improvement over the ajax-rpc calls over persistent http connection used in the past. WebSockets are easy to use, and being an internet standard have the support built into the networking components and programming libraries. Firewalls are typically configured to let HTTP (port 80) and HTTPS (port 443) traffic to pass through. WebSockets use the same ports (ws port 80, wss on port 443) for streaming connection as well. So, an application does not have to deal with any network configurations changes, when sending data over the WebSockets protocol.

Issues with TCP

WebSockets have a limitation. Being a TCP/IP based protocol, it suffers from head-of-line blocking issue due to packet-sequence-promise offered by the underlying TCP stack. TCP offers extensive error-checking, flow control mechanism and acknowledgment of data, and can lead to the slowdowns, when the data rates start to increase. In most internet applications with stream based communication requirements, these TCP advantages are worth the lag, but in some applications like games and live streaming, this can lead to a slowdown and stutter. For these low latency application where it is acceptable for a random packet to go missing, UDP protocol is a better suit.

Here is what a typical TCP/IP handshake looks like:

A new type of UDP based web standard called WebTransport is proposed in HTTP/3, and streaming applications like video and games etc. can take advantage of it. I am proposing, that we start using this delivery channel for streaming market data to the front end applications as well. A market data application has quite the same requirements regarding the latency and throughput, as a streaming video application. The slowdowns caused by the TCP due to re-transmissions and constant acknowledgments can be circumvented in market data applications as well. After all this mechanism of UDP multicast delivery has been proven for the low latency exchange data dissemination. We are just going to bring it to the cloud applications connected through the internet.

What does WebTransport bring

For the streaming video or even streaming market data, a single missing packet is hardly an issue. A video codec recognizes this and compensates for it by using various interpolation algorithms. In streaming marketdata world, a missed packet containing information about the stock price update is not as critical, since a subsequent packet will update the price anyways. The missing packet is even more irrelevant, because by the time it is received, the information contained in it is already stale. There is a need for a mechanism to send as many messages as quickly as possible, possibly out of order, and possibly unreliably from the server to a client.

WebTransport is an API offering low-latency, bidirectional, client-server messaging. It supports sending data both unreliably via the datagram API, and reliably via the streams API. Since it uses the QUIC protocol, these connections are less resource intensive to open and close compared to TCP. Also the API is HTTPS only, thereby enforcing security.

Here is how a server can send quotes over multicast and trades on streaming channels reliably:

Here in this representation, the client connects to the server over the HTTP and requests a subscription for an equity instrument like IBM trading on NYSE. The client opens both a stream, for the initial synchronization fields and trade data, and a datagram for high volume quotes. In a slightly different approach, both trades and quotes can be sent on the datagram channel, and periodic synchronization images can be sent on the stream channel.

From the browser/JavaScript perspective this API is quite similar to the WebSockets or WebRTC APIs. A datagram code in JavaScript would be something like this:

    	
            async function sendData(url, data) {
   const wt = new WebTransport(url);
   const writable = await wt.createUnidirectionalStream();
   const writer = writable.getWriter();
   await writer.write(data);
   await writer.close();
}

Since most market data applications are not written in browsers/JavaScript, this API structure is of little concern. Where WebTransport helps is - that it standardizes the UDP delivery on the internet. Being a HTTP/3 standard, all the network infrastructure components will develop to support and allow for this kind of traffic. So far, the Chromium based browsers i.e. Google Chrome and Microsoft Edge have developed a support for it.

As a new specification, WebTransport is still nascent, so it will be harder to get working until other tools are updated to work with it. WebSockets still offer a great deal of functionality, and as an established standard are fully supported by all modern browsers. For now, that means keeping our eyes and minds open and being ready to adapt.

What is your opinion of WebTransport? Do you think it brings any real advantage in data delivery, or do you have any other delivery topology suggestion? Please share your opinion on this here.

  • Register or Log in to applaud this article
  • Let the author know how much this article helped you
If you require assistance, please contact us here