Support for FIXP and SBE?

[chrjohn]

Just wanted to ask if there is demand for QFJ to support SBE and FIXP.

I've heard a few people over the last few months asking if QFJ supported SBE. My opinion at that time was that QFJ does not need to support it since there are other open source (Silverflash, Aeron) and commercial alternatives which do support SBE.

However it seems that people want to use SBE from within QFJ. But why? Do they expect QFJ to map the messages to the well-known tag-value representation? At the time I was asked I obviously forgot to ask that question.

Any input appreciated. Thank you. :)

[dia-susca]

I think QFJ is a very strong, stable implementation that is still active and used in lots of commercial implementations. It also follows closely the FIX specs while also allowing customization easily. Having a feature such as SBE and FIXP implemented in QFJ, to me, would mean the guarantee of a (relatively) bug-free, stable library that can handle everything, probably with a simple config-file switching between transport modes.
I don't know what the people asking the questions were referring to specifically, or how they wanted it to be implemented, but if QFJ can give me more features that allow me to brag to clients that I can also support better-performance protocols, I say "hells, yeah!"

[chrjohn]

Thanks for your thoughts on this @dia-susca

We probably would depend on one of the named open source implementations to prevent reinventing the wheel or introducing additional bugs but instead concentrate to bridge the gap between QFJ and the new protocols. But at the moment we are just collecting feedback, nothing has been decided yet.

[bismuth]

As @dia-susca says, QFJ is mature, stable and full-featured. That is a big reason for us to want to stay with it. Additionally, we are a small team where one of our tasks is to maintain our fix connectivity to a bunch of counterparties. Currently QFJ matches all requirements of our counterparties with a few configuration settings and that makes it very convenient. However, some of the counterparties are moving away from FIX towards only supporting FIXP or SBE. Implementing a second library such as one of the ones you suggest for a subset of counterparties would be additional work for no tangible upside.

So from our pov the benefit would be that we only have to implement one API to support all connections.

[chrjohn]

Thanks @bismuth
what does API mean in your case? E.g. having your application get messages via fromApp? Or accessing the messages via the known getFieldXYZ() methods? Or both? :) or something different?
Thank you

[bismuth]

Both. Ideally we'd only change some configuration to support FIXP/SBE over regular FIX assuming the decoded contents of the messages stay the same. I must admit that I haven't looked into FIXP / SBE deeply enough to confidently state this is possible at all, I am assuming it should be because the general descriptions and counterparty specific documentation I have read imply it should be, and I know of at least one commercial implementation that claims to support this (and also NASDAQ's ITCH and OUCH) throught one API.

[bismuth]

My underlying assumption here (to state it more clearly) is that fixp/sbe are basically a different transport layer and making QFJ support them is a -relatively- natural fit to the rest of the structure of the library.

[chrjohn]

The tag-value and SBE encoding are actually located on the same layer.

So if I understand correctly then a mapping between SBE and tag-value is desired? This could probably work. I didn't take a closer look at an SBE schema but IIRC it provided the FIX tag number, right?

[bismuth]

Specs I've seen talk about tags and values like fix, so I'd expect so yes. At the session level there are differences.

[mike-enker]

Agreeing with @bismuth, I wanted to add that the interest is in part driven by CME forcing to switch the "holdouts" to iLink3 (FIXP/SBE) protocol by the end of this year. I presume that most of entities are not critically dependent on latency, thus they are still staying in the text-based protocol and connecting through the convenience gateway. Those shops would be naturally happy with the ease of QF-J implementation, they are likely to use it already.