Imported from previous forum
As a reminder- The FAST Session Control Protocol 1.1 provided a full protocol for the inband exchange of FAST message templates. We should revisit this work if we are thinking about including this in FIXP or other protocols. I think where Jim is going with this is when we are successful in creating the FIX Service Profile (Machine readable rules of engagement) it would be good if there was a protocol for exchanging those documents and negotiating inband.
Oh I see, thank you for the response Donald! I will ruminate on this clarification and abandon this thread in further discussion.
Chaps,
Firstly, please note I’m not a technologist so bear with me if any of this is or should be ‘obvious’:
1 This is an excellent document, so well done to all involved.
2 The only annoyance I had was with the link in section 4.1 which doesn’t seem to work. Is it meant to, or is it just describing a syntax of something which should work?
3 General question on the message schemas - these are XML documents so could I, if I wanted to, actually wrap those in a FIX session of some type and pass those around electronically? If so, how would that be done?
4 I think it would be good to see a full-size example of an XML message schema definition that describes, say, a simple new order single (e.g. the mandatory field set in a FIX 4.0 message). Even better, an example, using that schema, of a sample FIX 4.0 new order message and its equivalent in SBE.
Jim.
-
Our pleasure.
-
The XSD for SBE RC2 is available on this site under the Tech/Specs tab. The URL is
http://www.fixtradingcommunity.org/pg/file/fplpo/read/1196759/simple-binary-encoding-release-candidate-2-xml-schema-xsd
When SBE reaches final draft, the XSD will be placed in well known place for download. However, firms should not depend on access to the FIX Trading Community web site to validate XML at run-time. We should make a note that. Technically, an XML namespace is a URI (identifier), not a URL (locator). The two concepts are often confused because they are written the same way.
-
In practice, message templates are often distributed out-of-band. However, the working group has discussed the possibility of a protocol for template exchange in-band. It was decided that such a protocol should work for all FIX encodings, not just for SBE. I’m sure that the High Performance Working Group would welcome idea submissions on that topic.
-
See section 7 for examples, including a simple order message.
Hi - this is very helpful - many thanks.
Hi All,
Excellent work, In regards to section 7, has anyone by chance built a complete or work in progress schema for FIX4.4 or any other dictionary yet?
In response to Andre…
First, please note that RC2 is not the latest version of SBE. See the RC3 spec that was approved December 2014. (This discussion should have been closed.) Nevertheless, the same question applies to all versions of SBE, so I’ll attempt to give an answer.
I have attempted to create a standard SBE message schema from the FIX Repository. If you’re not familiar with Repository, suffice it to say that it is a set of data files that hold the definitions of all FIX messages and fields. Published FIX specs are generated from the Repository. Unfortunately, this exercise did not prove useful because the general-purpose FIX specs and SBE are based on different principles. FIX specs are based on an inclusive principle – they contain the universe of all possible attributes for a given message across all markets and asset classes. Furthermore, messages such as Execution Report are overloaded for many use cases, such as order acknowledgement, fill, partial fill, rejection, cancel confirmation, etc.
On the other hand, SBE is founded on a minimalistic principle. Ideally, message templates should be as small and flat as possible. Although SBE does support optional fields, but they do have a cost. It is more efficient therefore, to create message templates for each specific use case with just the fields required for that transaction type and no more. Instead of creating a single message template for Execution Report, it is better to create separate ones for each of the use cases listed above, such as a template specifically for cancel confirmation.
In sum, although I was mechanically able to create a standard SBE message schema, the result would have been highly inefficient. A better approach is to design messages specifically targeted to a high performance trading environment.
Don - another point to note - the Unified Repository is quite misunderstood. The Unified Repository structure when defined purposely included metadata to support narrowing the specification for a specific implementation for instance:
repeatingGroups can include implMinOccurs, implMaxOccurs - to limit the number of repeating groups.
Fields can include implMinLength, implMaxLength (as can fieldReferences - which permits overriding).
Also, the unified repository format does not need to keep the entire universe of the specification. There is a proposal to support scenarios which are specific usage instances of a message. So you could define ExecutionReport - New as being different from ExecutionReport - Fill or Partial Fill for instance.
The unified repository with scenario extensions is already in use at quite a few firms, CME Clearing being one of them, there are a couple of major brokers and one interbroker dealer that are using the Unified Repository already to define multiple FIX service offerings.
What is missing is the dynamic behavior, which is being discussed within the subgroup working on FIX Service Profile.
Don, I join others, excellent work!
One question in regards to multicast recovery mechanism (section 5).
On which session do the Retransmission (response message) and the retransmitted messages are sent?
I see three! options:
- retransmission message and following messages are delivered on the multicast
- retransmission is delivered on a separate session, but and following messages delivered on the multicast
- retransmission and following messages are delivered on the separated session
Table in section 6.1, hints that the retransmission message is delivered on the a separated session (i.e. not on the multicast).
===
Also, in section 5.1.1.1 Recoverable: it is not clear what is the session UUID on the RetransmitRequest?
Perhaps change the words: instead of "RetransmitRequests must be delivered through a separate session"
write: “RetransmitRequests may be delivered through a separate transport”
So that recoveries are implemented over a separated transport, still using (or continuing / complementing) the very same session UUID.
Thanks,
Yuval
Yuval, it sounds like your comment pertains to FIXP RC2 rather than SBE RC2. That spec will soon be posted, and a discussed thread will be created for it. Please repost your comment under that topic when it is created. Thanks.