Further Thoughts About Fast Protocol

The primary purpose of the Fast protocol is to be used for market data distribution.

I would like to treat Fast protocol as a general supplement of the FIX protocol. FIX protocol is initially designed 10 years ago. The design is not perfect at all. Nevertheless it is still a very good protocol because it is designed very well to serve its main purpose and i is the de facto industry standard.

The FIX session is designed to be asynchronous message based with the "best effort guaranteed delivery" quality of service. Note the delivery is "best effort guaranteed" instead of simple "guaranteed" because if the link is down forever the message won't be delivered anyway. However, as long as the link is up with enough bandwidth and both sides are functioning correctly, the message will be eventually delivered.

The Fast session is designed to be very flexible. It doesn't have to guarantee the delivery of the message. So it is possible to deliver the message through Fast session with lower "quality of server" than a FIX session. While it may sound to be "inferior quality of servie", it is exactly what people want some times. And it makes fast a more light weight and more flexible than FIX protocol.

One concern about the fast protocol is that the encoding/decoding process is quite complicated and it may consume more CPU time. However it is still possible to build an efficient fast codec (encoder/decoder). It also helps to save bandwidth which is usually more limited than computing power.

Also the 64 bit and multi-core architecture is becoming more popular and the cost is dropping very fast. So the cost of CPU cycle will be less of a concern.

By combining FIX and fast protocol, we not only have more stand-compliant trading system, but also have more flexibility in implementing the system with the right choice of technology.