Brief Introduction to Fix and Fix JSON | Hacker News Reader

Brief Introduction to Fix and Fix JSON

fixparser.dev

13 pointslogotype13 comments

For anyone interested: it's an extraordinarily simple protocol (it predates complexity in protocols), consisting of key=value pairs, where the keys are all numbers (look up "fix tag dictionary" for 100 different decoder rings), everything's in text, and, IIRC, all the KVPs are separated by ASCII 01h (SOH), which by convention is written with the pipe filter. That's it, that's the protocol.

A real-world FIX gateway will demand a BodyLength tag, so you have to compute your message length, and it'll want SenderCompID and TargetCompID ("from" and "to", respectively). So it's like, well, that much more complicated.

The complexity in these systems will all be the semantics given to the messages and the zillion fields your vendor/partner supports.

Every. Single. Venue. Implements a different state transition for seemingly simple things like order ack, cancels, fills, etc.

And sometimes they lie in their docs about it. And sometimes their certification environments behave differently than production.

A pox on them all.

*note my info is over a decade old so maybe the poxy devils have changed their ways, but I doubt it.

hehe! spoiler alert: they haven't

If it meets the guidelines, this might make a good 'Show HN'. Show HN guidelines: https://news.ycombinator.com/showhn.html

Thanks! not sure if it meets the guidelines given that it is a paid product. cheers

Paid products are ok (so long as they are consistent with the rest of HN).

If in doubt, you can ask the mods using the contract link.

HN people have to be able to use the thingy, and signup forms don't count ("you have to have something more than a signup", per 'dang).

Isnt xml preferred in fix and not json?

xml/xsd is preferred as the schema definition, but the format "on the wire" is mostly tagvalue ASCII over TCP sockets these days (or binary using SBE if its latency sensitive e.g. HFT). JSON is relatively new in the FIX world. Some applications could encode fix in the front-end/browser and I can see some advantages of using FIX JSON in those scenarios and that's why we added support for it in FIXParser https://fixparser.dev

It's been like 10 years for me but all the systems I worked with just use the classic ASCII format; the last thing you'd want to do is inflate the messages with XML or JSON. Has that changed?

https://www.fixtrading.org/standards/json-online/#issues-for... I guess so.

exactly, it is the same. basically the simplest way to parse is to split the message into key/value pairs separated by \x01 (SOH), and then inflate/enrich the message with field names and enumerations to make the message more understandable. the protocol is deceptively simple and the complexity moved to the validation instead, here's where the specification + versioning + vendor specific fields become complex because the devil is definitively in the details

Mine was actually a question as well. My thought was because of nano second accuracy, json won't be preferred. XML causes no issues here just the bloat.

Reply on news.ycombinator.com