G4 Netcap Final Report
Application Service Report (Adrian Cheng)
Design Goals
The initial goal set out for this project is to create a web application, similar to corvil, in which we can see real time latency statistics from packets generated from trading activity. To achieve this, we have decided that it is important for us to create a realistic trading environment to more accurately grasp the different aspects and latency analytics that can be derived from a real trading environment.
Application Frontend
The whole frontend interface of this project is built in typescript, on top of the React.js framework. This is coupled with integrations with several other libraries to manage the different states and connections that the different pages would need to execute upon such as Jotai for state management, Socketio for websockets, TailwindCSS for styling, and several others.
The core of the front end is split up into two main panels, one is the navigation panel and the other is the main screen. When first opening up the website, you will be greeted with the main dashboard:
Note: If no previous trading simulation has been ran, this screen may be blank. Simply start up a exchange trader network to view the graph of your network in the dashboard.
The next page you can access when the trading simulation is running is the latency analytics page. In this page, you will be able to add and remove charts as needed, and to adjust each of the charts to display an assortment of data, including both running averages of the current latencies of packets, as well as the latency distribution histogram as shown below:
The third page you can access is the order explorer. Within the order explorer, you can browse through specific market order requests, or market data requests being sent within the trading simulation. You can then click on each request to view specific timing information regarding that specific request. Both absolute and relative timing information are in nanoseconds (ns). The relative timing information is based on when the request is first received within the exchange gateway, whilst the absolute timing information is the ns since epoch:
Finally, the last page, PCAP explorer, is the page where you can view the individual raw packets that are actually being sent throughout the simulated trading network. By clicking on a certain packet, you can see the raw data within the packet, as well as the ascii representation of the packet. To the leftmost side, you will see the parsed packet information regarding the packet:
Application Backend
The backend of the web application is based on the Nestjs framework. This backend not only provides the interface between the frontend and our MySQL database, but also serves as a communication hub between all of the nodes within the trade network, this includes all exchanges, traders, and packet capturing processes. The nest backend is the socketio server, in which the other trading simulation nodes would connect to as clients. This how we can achieve real time data analytics as the packets get recorded and sent to the database.
As for our database, we mainly use Prisma to help keep version control of our database layout. The following is the different tables we have layed out within our MySQL database:
In the final build of this project, only the tables OrderRequests, DataRequests, and RawPCAP are actually being used. The PingPong and Node tables were used in a previous version of this app, however, since we needed to change the way we are recording latency information from just doing internal metrics through a trace packet, the legacy tables PingPong and Node are deprecated.
Simulated Exchange
Within the simulated exchange does 2 very important steps. The first step is to respond to any trade requests being sent from a trader in a realistic manner, while the second step is to record every packet being sent to and from, and any internally sent packets for latency evaluation. Within each exchange is an actual internalized network, with several components at play:
What this diagram shows is the flow of packets from when the trader first sends to the exchange to when the exchange finally sends the response back to the trader. The packet initally enters the gateway of the exchange, which then deciphers whether the packet is a order request or a market data request.
If the packet is to be determined as an order request, it would then be forwarded to the order matching engine (OME). Once the packet has been received within the OME, a response would be generated, then sent to the ticker plant. The ticker plant would then perform two actions once the packet has been received. The first thing it does is to send it to an internal UDP server to broadcast the response out to every trader on the network. Simultaneously, the ticker would also connect back to the original gateway in which the trader has initially communicated with and send the response back privately to the original sender. Due to the speed differences between UDP and TCP protocols, the UDP broadcast will always be received first by the traders, compared to the private data feed.
On the other hand, if a market data request is to be sent, the gateway would route that packet towards the drop copy, in which the drop copy would generate a market data response which would be sent through the original gateway back to the trader.
Packet Capturing
Within each exchange lies a custom packet sniffing program. This program would capture all inbound and outbound packet traffic regarding any trading activities. The sniffer would then take the packets and parse them to the individual components which would then be sent to the MySQL database directly, directly to the RawPCAP table. This packet capturing program has been configured to have nanosecond precision allowing for all the nanosecond timestamps available within the frontend. The capturing program itself is written in C, mainly utilizing the libpcap library to capture the individual packets then parsing them to a JSON format.
Simulated Trader
The simulated trader is probably the simplest component of the simulated trading network. The trader simply generates randomized trading requests, at a ratio of 5 orders per 1 market data request. The trader will also randomly send these packets to all available exchanges at random intervals, thus allowing the exchange packet capturing to collect a more comprehensive view on the latency activity of the whole simulated trading network.