sneilan / stock-exchange Goto Github PK

This exchange should be downloadable and immediately runnable on a public internet. Without SSL, the exchange will still be secure but will be vulnerable to MITM attacks in a production setting. Also, if I implement websockets, browsers will complain.

It's not clear looking at the root directory how to use the server. There's a make.sh, a run.sh, a couple cpp files, Dockerfile, Cmake These files suggest four separate workflows to the end user.

1. Cmake -> Manual install and download libraries via source or apt.
2. make.sh / run.sh Run these directly to get started. But they can only be ran by docker.
3. cpp files -> Suggestive of importing into your own application
4. Dockerfile -> Run the docker but does not describe command. Does run.sh do this?

The root directory is confusing and should be cleaned up.

Create an html trading client with react.js that shows a level 3 depth chart and allows clients to log in and place trades. Dependent on #4 and #7

Create a GUI that shows latest stats about the server such as latest bid / ask, current volume, connected clients, open interest, and memory usage. Dependent on #3

Create a user management system so new users can log in, add funds to their account and begin trading.

Users should be saved locally to a sqlite3 database. When server starts up, users will be loaded from the database into memory. Later on, create an admin panel to create users on the fly. Create an interface to be able to swap databases to postgres. Balances are out of scope.

Gateway should be updated to allow authentication with a username and password. API authentication may come later. Higher level systems like main.cpp should not be concerned with authentication. SocketServer may be too low level.

Consider if we need to create JWT tokens and what security exists to prevent users from spoofing websockets.

Create a separate market data process that clients connect to and recieve all market data. This could be a pub-sub redis server. I'm limiting scope of this feature to L1 market data (current bid / ask). Leaving L2/L3 on the roadmap.

Review https://beej.us/guide/bgnet/html/split-wide/system-calls-or-bust.html (beej's guide to sockets)

The code for handling bid and ask is very similar. There's a gang of four pattern that would help merge the logic for handling bid and ask.

Before writing a GUI, document protocols, capabilities etc of the exchange. Users should be able to paste documentation into Chat GPT and be able to build their own trading GUI.

Create a signal handler for Control-C to shut down the exchange. This will make it easier to programmatically test if the exchange is able to be restarted. It will also let us tell clients when the exchange is shutting down.

Update the documentation with the improved python trading client.

When a user is first created, they should have a balance gifted to them by the administrator. Perform risk checks for every trade and make sure user has enough money in their wallet.

All trades should be written to an append only log file for replay. Also send these trades to a database for journaling.

Epoll will let the exchange handle thousands if not hundreds of thousands of clients at the same time. I could use io_uring but the exchange already uses ringbuffers to spool inbound and outbound messages.

Even though raw binary data would be faster to transmit, I think implementing the websocket protocol may be the right move because it will be easier for users to create trading clients. The wikipedia page for websockets has a great description of the protocol.

I need to understand the protocol, how hard it is to implement authentication and what the performance penalty will be for improved usability.

Make a user database. When clients authenticate, connect to user database and validate their credentials. Double check socket security for anything we need to prevent spoofing across the wire such as SSL.

I want all ring buffers, mmap blocks instantiated as close to main.cpp as possible. This way main.cpp becomes a diagram of information flow throughout the exchange. By reading a single file main.cpp, a reader should be able to see and understand how every component fits together without having to read any other files.

This will make it much easier to create market data.

Implementation Notes

• Use sqlite write ahead log to journal trades. Leverage SQLite for WAL and atomic commits instead of apache avro. Can tune settings for performance.
• Rotate trade journals by storing no more than 100k trades per file. Filename should be unique. Can put trade id / date etc in filename but rely on database because storing metadata in filenames is less scalable.
• Take checkpoints of market depth and event store in sqlite too.
• Track checkpoints in database to say which trade ID was latest when checkpoint taken.
• Restore checkpoints in sqlite to memory by deserialization.
• Do not save / restore checkpointed data by pure memory because the pointers to mmap buffers will misalign on reload. Plus saving memory data directly will also save any memory fragmentation.
• Replaying trade journals should result in correct system state.
• Add tests to make sure journals / replay work.
• Define data structures to store this.

A fly.io integration would allow newcomers to quickly deploy the server anywhere in the world. Part of the roadmap is making the exchange deployable in public facing servers such as $5 aws instances.

Create a docker-compose.yml so it's clear there's a main way to start the exchange. This also allows for integration with other services.