Hey All, I'm building an exchange based on the GNU/Open-Source Way, and I could use some help. Anyone interested in contributing? I'm going to start by making a paper market for gold, and need help with: 1. ENGINE: Creating the order book of priority queues (heaps), bid/ask price ladders, matching engine, and the like 2. FIX ACCEPTOR/INITIATOR: Creating a FIX connection between a client and the exchange. I've been working with a modified version of Quickfix, but I would really prefer to write our own FIX engine. 3. SOCKET PROGRAMMING. The model calls for users to remote into their colo equipment and run their algos remotely. This is great, because network latency becomes a non-factor. Yes, connection from your basement fund to the Ritchie colo equipment might be slow, but your algo is on the same LAN as everyone else. Once you modify, update, and run your algo, a C++ socket connection directly to the market acceptor enables you to trade at the same speeds as everyone else. I haven't timed it, but I'm looking for less than 500mcs market access times. Lots more on this... 4. SSL/SSH/Firewall. I suppose we need some form of security. 5. ALGOS. Algos to drive and test the market engine. Post/message me here on ET if you're interested. Check the links for the project home page and github repo. At a minimum, please star the repo. Thanks, Keith
Looks like a very interesting and ambitious project! I assume your end goal is to have a running exchange that competes with existing exchanges? fan27
Why dont you hire some of those indian & chinese programmers you reckon you can get for $7K a year (30 dollars a day). 'No-brainer' were the words you used on the other thread iirc.
Yes, the vision is for Ritchie to be an Alternative Trading System (ATS) with unprecedented transparency.
My thoughts exactly! Hard to take you seriously as a manager of a major software project Keith, given your naivety/stubbornness when it came to a bunch of people experienced in managing major software projects providing you advice you didn't want to hear. It's even crazier to think you think you could hire a random Indian dev for $7K a year to work on an ultra-low latency project where serious real dollars will eventually rely on the robustness of your software!
Architecting a system/application as micro services in Docker make it easy to outsource development to India and other low cost countries. The deliverable is a Git repo able to build a complete working docker image with micro service working according to the order specification. Input/Output API in chosen transport protocol. ProtoBuf (gRPC) is good for sequential API. For a asyncronous message passing API I would recommend using NanoMsg. HTTP REST is slow but may fit where latency is not an issue. This is a good video on the topic:
an exchange built by using docker microservices, protobufs? Looks like the links for the project home page and github repo have already disappeared.
Where do I mention "exchange" in my post? Do you think NYSE or Nasdaq is a monolith running on one single computer. I'm talking of micro services from a generic perspective. ProtoBuf is just vanila sockets with a standardised bin-packing protocol that is language agnostic and can be utilised by any programming language. Trading systems (including HFT) and exchanges are built up on asyncronous messaging as the transport layer, allowing for very high non-blocking and wait-free wire speed communications. Anyhow good luck to Keith with his endeavour.
No I don't think an exchange is a monolith. I don't think an exchange is made up of services running in docker created by some offshore developer. ProtoBuf has nothing to do with sockets. its serialization and slow,clumsy in 2017. Don't you think synchronous paths are also needed. You cannot just send a message and eventually act on it; there are constraints.
You are clueless and don't know what you are talking about, anything that uses IP is sockets, regardless if it is TCP or UDP.