tptacek 3 months ago

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.

  • kasey_junk 3 months ago

    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.

    • logotype 3 months ago

      hehe! spoiler alert: they haven't

brudgers 3 months ago

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

  • logotype 3 months ago

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

    • brudgers 3 months ago

      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.

      • tptacek 3 months ago

        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).

kp666 3 months ago

Isnt xml preferred in fix and not json?

  • logotype 3 months ago

    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

  • tptacek 3 months ago

    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?

    • logotype 3 months ago

      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

    • kp666 3 months ago

      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.