iLink 3 uses Simple Binary Encoding (SBE) optimized for low latency of encoding and decoding while keeping bandwidth utilization reasonably small. All FIX semantics are supported. This encoding standard describes the wire protocol for iLink 3 messages and is complimentary to other FIX standards for session protocol and application-level behavior.
This topic describes implementation of SBE in submitting orders on CME Globex and receiving order entry responses.
Contents
...
| Info |
|---|
iLink 3 Decoder -Real Logic Ltd. and Informatica have collaborated to create open source tools that provide extensive support for Simple Binary Encoding (SBE), the messaging standard developed through the Financial Information Exchange (FIX) Trading Community. The SBE decoders will create an environment that can be used directly by customers or treated as a reference implementation that can be extended into custom solutions tailored to individual customer's needs. The information and tool are open to the public under an Apache Public License and are available here. Client System - client systems using Real Logic SBE decoder, iLink 3 message schema supports the Real Logic version 1.25.1 or lower.
|
Binary Encoding
Binary encoding provides direct data access without complex transformations or conditional logic by:
...
- An overall message length including headers to support framing.
- An identifier of the encoding used in the message payload. This supports selecting the correct decoder in the case where multiple message encodings are used on a session. It also aids tools such as protocol analyzers to identify message protocols contained in network packets.
| Info |
|---|
The framing standard specifies that the framing header will always be encoded in little-endian byte order. |
Simple Open Framing Header (SOFH) (4 bytes) | SBE Header (8 bytes) | SBE Message (Variable Length) |
|---|
Message Length: 2 bytes - Overall message length including headers to support framing
| Block Length: 2 bytes - The total space reserved for the root level of the Message
| Customer to CME Globex Messages Example: - New Order Single
- Order Cancel Replace Request
- Order Cancel Request
- Mass Quote
|
Encoding Type: 2 bytes - CME SBE Version 1.0 Little-endian: 0xCAFE
- Identifier of the encoding used in the message payload
| TemplateID: 2 bytes - Message Template Identifier
| CME Globex to Customer Messages Example: - Execution Reports
- Mass Quote AcknowledgementAcknowledgment
- Business Rejects
|
| SchemaID: 2 bytes - Identifier of the Message Schema that contains the Template
|
|
| Version: 2 bytes - Version of the Message Schema in which the Message is defined
|
|
...
| Panel |
|---|
|
<ns2:message id="514" description="NewOrderSingle" name="NewOrderSingle514" semanticType="D" blockLength="116"> <field id="44" description="Price per share or contract. Conditionally required if the order type requires a price (not market orders)" name="Price" semanticType="Price" type="PRICENULL9" offset="0"/>
<field id="38" description="Number of shares or contracts ordered" name="OrderQty" semanticType="int" type="uInt32" offset="8"/>
<field id="48" description="Security ID as defined by CME. For the security ID list, see the security definition messages" name="SecurityID" semanticType="int" type="Int32" offset="12"/>
<field id="54" description="Side of order" name="Side" semanticType="int" type="SideReq" offset="16"/>
<field id="9726" description="Sequence number as assigned to message" name="SeqNum" semanticType="int" type="uInt32" offset="17"/>
<field id="5392" description="Operator ID. Should be unique per Firm ID. Assigned value used to identify specific message originator. Represents last individual or team in charge of the system which modifies the order before submission to the Globex platform, or if not modified from initiator (party role=118), last individual or team in charge of the system, which submit the order to the Globex platform" name="SenderID" semanticType="String" type="String20Req" offset="21"/>
<field id="11" description="Unique identifier for Order as assigned by the buy-side (institution, broker, intermediary etc.). Uniqueness must be guaranteed within a single trading day. Firms, particularly those which electronically submit multi-day orders, trade globally or throughout market close periods, should ensure uniqueness across days, for example by embedding a date within the ClOrdID field" name="ClOrdID" semanticType="String" type="String20Req" offset="41"/>
<field id="1505" description="Refers to the ID of the related PartyDetailsDefinitionRequest message which will logically be tied to this message" name="PartyDetailsListReqID" semanticType="int" type="uInt64" offset="61"/>
<field id="2422" description="Use OrderRequestID to identify a request to enter, modify or delete an order and echo the value on the ExecutionReport representing the response" name="OrderRequestID" semanticType="int" type="uInt64" offset="69"/>
<field id="5297" description="Time when the message is sent. 64-bit integer expressing the number of nano seconds since midnight January 1, 1970." name="SendingTimeEpoch" semanticType="int" type="uInt64" offset="77"/>
<field id="99" description="The stop price of a stop protect or stop limit order. (Conditionally required if OrdType = 3 or 4)." name="StopPx" semanticType="Price" type="PRICENULL9" offset="85"/>
<field id="9537" description="Text describing sender's location (i.e. geopraphic location and/or desk)" name="Location" semanticType="String" type="String5Req" offset="93"/>
<field id="110" description="Minimum quantity of an order to be executed" name="MinQty" semanticType="int" type="uInt32NULL" offset="98"/>
<field id="1138" description="The quantity to be displayed . Required for iceberg orders. On orders specifies the qty to be displayed, on execution reports the currently displayed quantity" name="DisplayQty" semanticType="int" type="uInt32NULL" offset="102"/>
<field id="432" description="Date of order expiration (last day the order can trade), always expressed in terms of the local market date. Applicable only to GTD orders which expire at the end of the trading session specified. This has to be a future or current session date and cannot be in the past." name="ExpireDate" semanticType="LocalMktDate" type="LocalMktDate" offset="106"/>
<field id="40" description="Order type" name="OrdType" semanticType="char" type="OrderTypeReq" offset="108"/>
<field id="59" description="Specifies how long the order remains in effect" name="TimeInForce" semanticType="int" type="TimeInForce" offset="109"/>
<field id="1028" description="Indicates if the order was initially received manually (as opposed to electronically)" name="ManualOrderIndicator" semanticType="int" type="ManualOrdIndReq" offset="110"/>
<field id="18" description="Instructions for order handling on exchange. Since more than one instruction is applicable to an order, this field can represent those using a bitset." name="ExecInst" semanticType="MultipleCharValue" type="ExecInst" offset="111"/>
<field id="5906" description="Identifies whether the order should be treated as passive (will not match when entered) or aggressive (could match when entered); default behavior when absent is aggressive" name="ExecutionMode" semanticType="char" type="ExecMode" offset="112"/>
<field id="9373" description="New field added to capture if an order was submitted for market making obligation or not. Applicable only for EU fixed income markets" name="LiquidityFlag" semanticType="int" type="BooleanNULL" offset="113"/>
<field id="6881" description="Boolean: flags a managed order" name="ManagedOrder" semanticType="int" type="BooleanNULL" offset="114"/>
<field id="5409" description="Indicates the type of short sale. Will not be used for Buy orders but Sell orders should have this tag populated for MiFID" name="ShortSaleType" semanticType="int" type="ShortSaleType" offset="115"/> </ns2:message> |
This standard describes how fields are encoded and the general structure of messages. The content of a message type is specified by a message schema. A message schema tells which fields belong to a message and their location within a message. Additionally, the metadata describes valid value ranges and information that need not be sent on the wire, such as constant values. For iLink 3 Simple Binary Encoding, message schemas are expressed as an XML template.Message Schema.
A FIX template corresponds to a FIX message type, and uniquely identifies an ordered collection of fields. The template also includes syntax indicating the type of field and transfer decoding to apply. A template is communicated between CME Group and client systems in XML syntax using the Simple Binary Encoding XML schema. The XML format is human- and machine-readable and can be used for authoring and storing FIX templates.
Each template has a unique Template ID that describes the format of the binary encoded message. A Template ID is present in every message to provide a reference to the correct template. The The Template ID is unique and is included in every message header, allowing the client system to apply the correct schema to the message upon receiving it.
...
<ns2:messageSchema id="8" xsi:schemaLocation="http://www.fixtradingcommunity.org/pg/file/fplpo/read/1196759/simple-binary-encoding-rc2xsd SimpleBinary-RC2.xsd" byteOrder="littleEndian"
...
package="iLinkBinary"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns2="http://www.fixprotocol.org/ns/simple/1.0">
Schema Format
The schema file is constructed of several sections including the following:
...