Communicating with Market Participants

In this chapter, we will build the order gateway component at the electronic trading exchange that is responsible for accepting client connections, handling requests, and publishing responses to clients about their orders when there are updates. Fairness, low latency, and low jitter (latency variance) are important requirements here to facilitate high-frequency trading participants. We will also build the component that publishes market data from the trading exchange. These market data updates are designed to allow clients to construct the order book of all client orders that the electronic trading exchange holds. These market updates need to be sent out as soon as possible when there are order updates and when matches occur, so the focus will be on super-low-latency performance. Additionally, the exchange needs to periodically provide snapshots of the order book for participants that drop packets or start after the market is already open.

...

Technical requirements

All the code for this book can be found in the GitHub repository for this book at https://github.com/PacktPublishing/Building-Low-Latency-Applications-with-CPP. The source code for this chapter can be found in the Chapter7 directory in the repository.

It is important that you have read and understood the design of the electronic trading ecosystem presented in the Designing Our Trading Ecosystem chapter. The components we build in this chapter will interact with the matching engine we built in the Building the C++ Matching Engine chapter, so we assume you are familiar with that. As before, we will use the building blocks we built in the Building the C++ Building Blocks for Low-Latency Applications chapter.

Defining the market data protocol and order data protocol

Before we build the components inside the trading exchange that publish market data updates and receive and respond to client requests, we need to finalize the protocol. The protocol needs to be publicly available so that market participants who want to connect to the exchange, process updates, and send order requests can build their software. The protocol is the language that the exchange and market participants will use to communicate. We will have two protocols – one for the format of the market data updates and one for the format to send order requests and receive order responses in.

Designing the market data protocol

For the market data protocol, we will define an internal format that the matching engine uses, and a public format meant for the market participants. We saw the internal matching format, that is, the MEMarketUpdate struct, in the Building the Matching Engine chapter, in the Defining the operations...

Building the order gateway server

In this section, we will start building the order gateway server infrastructure, which is responsible for setting up a TCP server for clients to connect to. The order gateway server also needs to process incoming client requests from different clients in the order in which they arrive and forward those to the matching engine. Finally, it also needs to receive the order responses from the matching engine and forward them to the correct TCP connection for the corresponding market participant. We will revisit the design of the order gateway server and how it interacts with the matching engine and the market participants, as follows.

Figure 7.1 – Order gateway server and its subcomponents

To refresh your memory, the order gateway server receives new TCP connections or client requests on established TCP connections. Then, those requests go through a FIFO sequencer stage to make sure that requests are processed in the...

Building the market data publisher

The last component in the electronic trading exchange we need to build is the market data publisher, which is how the exchange publishes public market data updates to any market participants that need it. Revisiting the design of the market data publisher, we present a diagram of how this component communicates with the matching engine and publishes to the market data participants over UDP, as follows.

Figure 7.2 – Market data publisher and its subcomponents

We would like to remind you that the purpose and design of the market data publisher were discussed in detail in the Designing Our Trading Ecosystem chapter, specifically in the Understanding the layout of the electronic trading ecosystem and Understanding how an exchange publishes information to participants sections. We would strongly encourage you to revisit those sections to follow along as we build our market data publisher component.

Let us get started...

Building the main exchange application

In this final section of the chapter, as well as the final section of the electronic trading exchange discussion, we will build the main exchange application. This will be a standalone binary application that will run an order gateway server, the matching engine, and the market data publisher and perform the following tasks:

• The order gateway server accepts client connections and client requests.
• The matching engine builds the limit order book.
• The matching engine also performs matching between client orders.
• The matching engine and the order gateway server publish client responses.
• The matching engine and the market data publisher publish incremental market data updates in response to client requests.
• The market data publisher also synthesizes and periodically publishes a full snapshot of the order book.

The complete design is presented in the following diagram.

Figure 7.4 –...

Summary

This chapter was dedicated to building the order gateway server and the market data publisher components. We also combined the matching engine component we built in the previous chapter with the order gateway server and market data publisher components we built in this chapter to build the final trading exchange main application.

First, we defined the public market data protocol that will be used by the exchange to publish data on the wire and used by the clients to write market data consumer applications. We performed a similar task with the order gateway protocol so that client applications can understand the format of the client requests that they send to the exchange’s order gateway server and receive responses from.

We built the order gateway server, whose design we established in the Designing Our Trading Ecosystem chapter. We built the OrderServer class, which builds and runs TCPServer, to accept and manage TCP client connections. We added functionality...