3 ms·

FIX is less ergonomic than JSON, that is not in question. FIX is much faster to generate and parse than JSON, and much easier to deal with than bespoke binary f

FIX is less ergonomic than JSON, that is not in question. FIX is much faster to generate and parse than JSON, and much easier to deal with than bespoke binary feeds. I think FIX makes the right tradeoffs. I don't understand what you mean regarding killing someone else's session. You can reset sequence numbers in the login message.

amluto 5y ago
There is absolutely no reason that FIX should be faster to generate than JSON. I agree that one could plausibly parse it faster. JSON wasn’t meant as a real comparison though — FIX is structurally much more like protocol buffers, but protocol buffers are much better. As for sequence numbers: suppose your session drops. You’ve received the message with sequence number 5, but you’ve missed 6 and 7. You’ve sent 10 and 11 but the other end only got 10. Now someone (your own misconfigured software or someone else) connects and sends Logon to the server with your comp id, with sequence number 11 but the wrong authentication data. What is even supposed to happen? The session now contains two different message 11s to the server. It’s broken. You can (sometimes) recover by resetting sequence numbers, but that defeats the entire purpose of having sequence numbers in the first place: the server was supposed to recover the original message 11 on a reconnection attempt and correctly handle it as a possible duplicate. (As a practical matter merely experiencing network trouble during a reconnection also seems to break everything, mostly because common FIX implementations are terrible.) I suppose it must be possible to be so deeply entrenched in the FIX ecosystem that this makes any sense at all, but the whole protocol is backwards. You should connect, authenticate that connection, and then run the session protocol inside the authenticated connection. The Logon should not be sequenced — that gets the layering backwards.
- amluto 5y ago
  And replying further: this isn’t about whether FIX makes the right trade offs. This is about the fact that, even in the position in design space that FIX occupies, FIX is terrible. One could have easily designed a protocol with the same level of security as FIX and precisely the same (application) message semantics and schema that actually worked well. It wouldn’t even be very different from FIX. All you would need is proper layering, group delimiters, delimiters for entire messages, and either proper escaping or length-prefixing of fields. (And length-prefixing would make parsing quite a bit faster without needing to resort to vectorized searches for where fields and groups end.)

amluto 5y ago

There is absolutely no reason that FIX should be faster to generate than JSON. I agree that one could plausibly parse it faster. JSON wasn’t meant as a real comparison though — FIX is structurally much more like protocol buffers, but protocol buffers are much better. As for sequence numbers: suppose your session drops. You’ve received the message with sequence number 5, but you’ve missed 6 and 7. You’ve sent 10 and 11 but the other end only got 10. Now someone (your own misconfigured software or someone else) connects and sends Logon to the server with your comp id, with sequence number 11 but the wrong authentication data. What is even supposed to happen? The session now contains two different message 11s to the server. It’s broken. You can (sometimes) recover by resetting sequence numbers, but that defeats the entire purpose of having sequence numbers in the first place: the server was supposed to recover the original message 11 on a reconnection attempt and correctly handle it as a possible duplicate. (As a practical matter merely experiencing network trouble during a reconnection also seems to break everything, mostly because common FIX implementations are terrible.) I suppose it must be possible to be so deeply entrenched in the FIX ecosystem that this makes any sense at all, but the whole protocol is backwards. You should connect, authenticate that connection, and then run the session protocol inside the authenticated connection. The Logon should not be sequenced — that gets the layering backwards.

amluto 5y ago
And replying further: this isn’t about whether FIX makes the right trade offs. This is about the fact that, even in the position in design space that FIX occupies, FIX is terrible. One could have easily designed a protocol with the same level of security as FIX and precisely the same (application) message semantics and schema that actually worked well. It wouldn’t even be very different from FIX. All you would need is proper layering, group delimiters, delimiters for entire messages, and either proper escaping or length-prefixing of fields. (And length-prefixing would make parsing quite a bit faster without needing to resort to vectorized searches for where fields and groups end.)