Imported from previous forum
The values are in GitHub, but as I said, they are not official. It is implementation, not standard specification. In other words, non-normative.
To get them in FIXimate, we need to create a FIX Repository file for FIXP, as there is for FIXT 1.1. Additionally, we would publish an official SBE message schema file (XML), as I said.
Just to clarify, those are binary values in github? Will these new FIXP fields along with their associated ID’s also get added to FIXimate? If so then wouldn’t FPL be assigning those ID’s?
The plan is to issue an addendum to the FIXP standard with an official SBE message schema for FIXP session messages. Aditya, hopefully, you can help create that.
(The FIXP standard is not tied to a particular wire format. It can be implemented with SBE or another binary encoding.)
Unofficially, I have assigned arbitrary message IDs in the silverflash implementation here:
https://github.com/FIXTradingCommunity/silverflash/blob/master/silverflash-core/src/main/java/org/fixtrading/silverflash/fixp/messages/MessageType.java The numbers are at the upper range of uint16.
SBE field tag numbers only appear in metadata (XML message schema); they are not sent on the wire.
(Historical note: the XMIT specification assigned field tags and message IDs in a 32 bit range. This seems a greater domain than necessary for SBE since SBE message IDs and field tags are further qualified by a unique schema number; tags need not be globally unique.)
Just out of curiosity when will the tag numbers (field ID’s) be assigned for the new FIXP fields? The field names are there but we also need corresponding ID numbers to identify them properly in an SBE schema. For example:
field name=“ClientFlow” id="?" type=“FlowType"
field name=“NextSeqNo” id=”?" type=“u64Int"
field name=“FromSeqNo” id=”?" type=“u64Int”
Also for fields like MessageType etc are we using existing ID’s? For example:
field name=“MessageType” id=“35” type=“MessageType”
Yes, there is an open source project under development as a reference implementation of FIXP and other FIX high performance layers.
The code resides in GitHub at:
The project wiki is here:
As you alluded to, Silver Flash intends to be the successor to QuickFIX for modern, high-performance protocols.
As I have said elsewhere, contributions to this project from the developer community are welcome.
Just wanted to clarify if there are any plans afoot for an open source implementation to support FIXP? Has anyone explored this with QuickFix? (since it is a popular open source FIX engine)
No, we don’t need to wait for comment period to end to perform tasks. (It’ almost over anyway.)
I added issues to GitHub project:
Add FIXP messages to FIX Repository #6
SBE message schema for FIXP #7
See https://github.com/FIXTradingCommunity/fixp-specification/issues
Okay thanks, does that have to wait until the comment period is over or is that something which could be started in parallel?
Okay great thanks for confirming, I will be in touch with you offline.
This proposal from the High Performance Working Group provides a FIX session layer for high performance. FIX Performance Session Layer (FIXP) is a lightweight protocol introduced to provide an open industry standard for high performance computing requirements currently encountered by the FIX Community.
Release Candidate 2 of FIXP supports point-to-point sessions with negotiable delivery guarantees, including support for asymmetric flows common to trading environments. Additionally, this draft of the standard has been expanded to provide a protocol for multicast flows, such as market data or reference data.
The technical standard specification for the Release Candidate 2 for the FIX Performance Session Layer can be found here: http://www.fixtradingcommunity.org/pg/structure/tech-specs/fix-performance-session-layer
The proposal is following the technical standards review process described in the document found here: http://www.fixtradingcommunity.org/mod/file/view.php?file_guid=46944
This release candidate now enters a public comment period in which public review and feedback is encouraged. The public comment period will run for a period of 90 days beginning on the 14th of September 2015.
Please post feedback, comments, and questions as replies to this discussion thread.