├── .gitignore ├── LICENSE ├── README.md ├── v1-0-DRAFT ├── doc │ ├── 00Contents.md │ ├── 00Title.md │ ├── 01Introduction.md │ ├── 02Requirements.md │ ├── 03CommonFeatures.md │ ├── 04PointToPointSessionProtocol.md │ ├── 05MulticastSessionProtocol.md │ ├── 06SummaryOfSessionMessages.md │ ├── 07UsageExamples.md │ ├── 08RulesOfEngagement.md │ ├── FIXDisclaimerTechStd.md │ ├── FIXP.sh │ ├── FIXP.yaml │ ├── FIX_TechStd_Style_MASTER.docx │ └── media │ │ ├── FlowFinalization.png │ │ ├── Idempotent.png │ │ ├── Retransmission.png │ │ ├── RetransmissionReject.png │ │ ├── RetransmitViolation.png │ │ ├── SessionEstablishment.png │ │ ├── SessionNegotiation.png │ │ ├── UnbindTransport-TCP.png │ │ ├── UnbindTransport-UDP.png │ │ └── image1.jpeg └── resources │ ├── FixRepositoryForFIXP.xml │ ├── OrchestraForFIXP.xml │ └── SBEschemaForFIXP.xml ├── v1-0-RC2 └── doc │ ├── 00Contents.md │ ├── 00Title.md │ ├── 01Introduction.md │ ├── 02Requirements.md │ ├── 03CommonFeatures.md │ ├── 04PointToPointSessionProtocol.md │ ├── 05MulticastSessionProtocol.md │ ├── 06SummaryOfSessionMessages.md │ ├── 07UsageExamples.md │ ├── 08RulesOfEngagement.md │ └── media │ ├── FlowFinalization.png │ ├── Idempotent.png │ ├── Retransmission.png │ ├── RetransmissionReject.png │ ├── RetransmitViolation.png │ ├── SessionEstablishment.png │ ├── SessionNegotiation.png │ ├── UnbindTransport-TCP.png │ ├── UnbindTransport-UDP.png │ └── image1.jpeg ├── v1-0-RC3 ├── doc │ ├── 00Contents.md │ ├── 00Title.md │ ├── 01Introduction.md │ ├── 02Requirements.md │ ├── 03CommonFeatures.md │ ├── 04PointToPointSessionProtocol.md │ ├── 05MulticastSessionProtocol.md │ ├── 06SummaryOfSessionMessages.md │ ├── 07UsageExamples.md │ ├── 08RulesOfEngagement.md │ └── media │ │ ├── FlowFinalization.png │ │ ├── Idempotent.png │ │ ├── Retransmission.png │ │ ├── RetransmissionReject.png │ │ ├── RetransmitViolation.png │ │ ├── SessionEstablishment.png │ │ ├── SessionNegotiation.png │ │ ├── UnbindTransport-TCP.png │ │ ├── UnbindTransport-UDP.png │ │ └── image1.jpeg └── resources │ ├── FixRepositoryForFIXP.xml │ └── SBEschemaForFIXP.xml ├── v1-0-RC4 ├── doc │ ├── 00Contents.md │ ├── 00Title.md │ ├── 01Introduction.md │ ├── 02Requirements.md │ ├── 03CommonFeatures.md │ ├── 04PointToPointSessionProtocol.md │ ├── 05MulticastSessionProtocol.md │ ├── 06SummaryOfSessionMessages.md │ ├── 07UsageExamples.md │ ├── 08RulesOfEngagement.md │ └── media │ │ ├── FlowFinalization.png │ │ ├── Idempotent.png │ │ ├── Retransmission.png │ │ ├── RetransmissionReject.png │ │ ├── RetransmitViolation.png │ │ ├── SessionEstablishment.png │ │ ├── SessionNegotiation.png │ │ ├── UnbindTransport-TCP.png │ │ ├── UnbindTransport-UDP.png │ │ └── image1.jpeg └── resources │ ├── FixRepositoryForFIXP.xml │ └── SBEschemaForFIXP.xml ├── v1-0-STANDARD ├── doc │ ├── 01Introduction.md │ ├── 02Requirements.md │ ├── 03CommonFeatures.md │ ├── 04PointToPointSessionProtocol.md │ ├── 05MulticastSessionProtocol.md │ ├── 06SummaryOfSessionMessages.md │ ├── 07UsageExamples.md │ ├── 08RulesOfEngagement.md │ ├── FIXDisclaimerTechStd.md │ ├── FIXP.sh │ ├── FIXP.yaml │ ├── FIX_TechStd_Style_MASTER.docx │ ├── media │ │ ├── FlowFinalization.png │ │ ├── Idempotent.png │ │ ├── Retransmission.png │ │ ├── RetransmissionReject.png │ │ ├── RetransmitViolation.png │ │ ├── SessionEstablishment.png │ │ ├── SessionNegotiation.png │ │ ├── UnbindTransport-TCP.png │ │ ├── UnbindTransport-UDP.png │ │ └── image1.jpeg │ └── publication │ │ ├── FIX_Performance_Session_Layer_V1.0.docx │ │ └── FIX_Performance_Session_Layer_V1.0.pdf └── resources │ ├── FixRepositoryForFIXP.xml │ ├── OrchestraForFIXP.xml │ └── SBEschemaForFIXP.xml └── v1-1 ├── doc ├── 01Introduction.md ├── 02Requirements.md ├── 03CommonFeatures.md ├── 04PointToPointSessionProtocol.md ├── 05MulticastSessionProtocol.md ├── 06SummaryOfSessionMessages.md ├── 07UsageExamples.md ├── 08RulesOfEngagement.md ├── FIXDisclaimerTechStd.md ├── FIXP.cmd ├── FIXP.sh ├── FIXP.yaml ├── FIXP_ISO.yaml ├── FIX_TechStd_Style_MASTER.docx ├── ISOBiblio.md ├── ISOCopyright.md ├── ISOForeword.md ├── ISOIntro.md ├── ISO_TechStd_Style_MASTER.docx ├── README.md ├── media │ ├── FlowFinalization.png │ ├── Idempotent.png │ ├── Retransmission.png │ ├── RetransmissionReject.png │ ├── RetransmitViolation.png │ ├── SessionEstablishment.png │ ├── SessionNegotiation.png │ ├── UnbindTransport-TCP.png │ ├── UnbindTransport-UDP.png │ └── image1.jpeg └── publication │ ├── FIXP - Technical Proposal v1.1 RC1.docx │ ├── FIXP Technical Draft Standard v1.1.docx │ ├── FIXP Technical Proposal Draft Standard v1.1.docx │ ├── FIXP Technical Standard v1.1 RC1.docx │ ├── FIXP-Technical-Draft-Standard-v1.1.pdf │ ├── FIXP-Technical-Proposal-Draft-Standard-v1.1-1.pdf │ ├── FIXP-Technical-Proposal-v1.1-RC1.pdf │ └── FIXP-Technical-Standard-v1.1-RC1.pdf └── resources ├── FixRepositoryForFIXP.xml └── SBEschemaForFIXP.xml /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | .settings 3 | .project 4 | target 5 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/LICENSE -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # fixp-specification 2 | This project contains specifications and resources for FIX Performance session layer (FIXP). 3 | 4 | 5 | ## Protocol stack 6 | FIXP is part of a family of protocols created by the High Performance Working Group 7 | of the FIX Trading Community. FIXP is a session layer protocol (layer 5). 8 | 9 | ## Versions 10 | 11 | The planned lifecycle of this project is to work iteratively in a series of release candidates. After each release candidate is approved, it will be exposed to public review. Issues may be entered here in GitHub or in a discussion forum on the FIX Trading Community site. When a version is considered complete, the last release candidate will be promoted to Draft Standard. 12 | 13 | Promotion to final Technical Standard is contingent on successful public review and evidence of at least two interoperable implementations. 14 | 15 | All approved versions of the FIXP specification are available as PDF documents at [FIX Performance Session Layer (FIXP)](https://www.fixtrading.org/standards/fixp/). 16 | 17 | ### Version 1.1 Draft Standard 18 | 19 | Version 1.1 was approved for publication by the Global Technical Committee on April 18, 2019. A guideline for using FIXP over Websocket transport has been added to the specification. Comments may be entered in the FIX discussion forum (https://forum.fixtrading.org/). Pull requests and issues may be entered in this GitHub project for errata or proposed enhancements. 20 | 21 | ### Version 1.0 Technical Standard 22 | Version 1.0 Technical Standard has been finalized and was approved for publication by the Global Technical Committee on April 15, 2021. Pull requests will only be accepted for errata. 23 | 24 | Release Candidates and the Draft Standard for Version 1.0 are included here for reference only. 25 | 26 | ## License 27 | FIXP specifications are © Copyright 2014-2021 FIX Protocol Ltd. 28 | 29 | Creative Commons License
FIX Performance Session Layer specification by FIX Protocol Ltd. is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.
Based on a work at https://github.com/FIXTradingCommunity/fixp-specification. 30 | 31 | ## Implementations 32 | 33 | We will post links to open source implementations of FIXP. Implementors, contact one 34 | of the owners of this repository. 35 | 36 | ### Reference Implementation: silverflash 37 | An open-source implementation of FIXP is available in GitHub project [FIXTradingCommunity/silverflash](https://github.com/FIXTradingCommunity/silverflash). That project also demonstrates FIX standards Simple Binary Encoding (SBE) and Simple Open Framing Header (SOFH). 38 | 39 | ### Project Conga 40 | [Project Conga](https://github.com/FIXTradingCommunity/conga) is a proof of concept of high performance FIX semantics over WebSocket with SBE and JSON encodings. At the session layer, it employs FIXP for session durability, reliability, and recoverability. 41 | -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/00Contents.md: -------------------------------------------------------------------------------- 1 | Contents 2 | ======== 3 | 4 | [Title](00Title.md) 5 | 6 | [1. Introduction](01Introduction.md) 7 | 8 | [2. Requirements](02Requirements.md) 9 | 10 | [3. Common Features](03CommonFeatures.md) 11 | 12 | [4. Point to Point Session Protocol](04PointToPointSessionProtocol.md) 13 | 14 | [5. Multicast Session Protocol](05MulticastSessionProtocol.md) 15 | 16 | [6. Summary of Session Messages](06SummaryOfSessionMessages.md) 17 | 18 | [7. Appendix A: Usage Examples](07UsageExamples.md) 19 | 20 | [8. Appendix B: Rules of Engagement](08RulesOfEngagement.md) -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/00Title.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | # FIX Performance Session Layer 6 | 7 | ## Technical Specification 8 | 9 | ## Draft Standard 10 | 11 | August 16, 2018 12 | 13 | **THIS DOCUMENT IS A DRAFT STANDARD FOR A PROPOSED FIX TECHNICAL STANDARD. A DRAFT STANDARD HAS BEEN APPROVED BY THE GLOBAL TECHNICAL COMMITTEE AS THE FINAL STEP IN CREATING A NEW FIX TECHNICAL STANDARD. POTENTIAL ADOPTERS ARE STRONGLY ENCOURAGED TO BEGIN WORKING WITH THE DRAFT STANDARD AND TO PROVIDE FEEDBACK TO THE GLOBAL TECHNICAL COMMITTEE AND THE WORKING GROUP THAT SUBMITTED THE PROPOSAL. THE FEEDBACK TO THE DRAFT STANDARD WILL DETERMINE WHEN TWO INTEROPERABLE IMPLEMENTATIONS HAVE BEEN ESTABLISHED AND THE DRAFT STANDARD CAN BE PROMOTED TO BECOME A NEW FIX TECHNICAL STANDARD.** 14 | 15 | 16 | 17 | 18 | DISCLAIMER 19 | 20 | THE INFORMATION CONTAINED HEREIN AND THE FINANCIAL INFORMATION EXCHANGE PROTOCOL (COLLECTIVELY, THE "FIX PROTOCOL") ARE PROVIDED "AS IS" AND NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL MAKES ANY REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED, AS TO THE FIX PROTOCOL (OR THE RESULTS TO BE OBTAINED BY THE USE THEREOF) OR ANY OTHER MATTER AND EACH SUCH PERSON AND ENTITY SPECIFICALLY DISCLAIMS ANY WARRANTY OF ORIGINALITY, ACCURACY, COMPLETENESS, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SUCH PERSONS AND ENTITIES DO NOT WARRANT THAT THE FIX PROTOCOL WILL CONFORM TO ANY DESCRIPTION THEREOF OR BE FREE OF ERRORS. THE ENTIRE RISK OF ANY USE OF THE FIX PROTOCOL IS ASSUMED BY THE USER. 21 | 22 | NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL SHALL HAVE ANY LIABILITY FOR DAMAGES OF ANY KIND ARISING IN ANY MANNER OUT OF OR IN CONNECTION WITH ANY USER'S USE OF (OR ANY INABILITY TO USE) THE FIX PROTOCOL, WHETHER DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL (INCLUDING, WITHOUT LIMITATION, LOSS OF DATA, LOSS OF USE, CLAIMS OF THIRD PARTIES OR LOST PROFITS OR REVENUES OR OTHER ECONOMIC LOSS), WHETHER IN TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), CONTRACT OR OTHERWISE, WHETHER OR NOT ANY SUCH PERSON OR ENTITY HAS BEEN ADVISED OF, OR OTHERWISE MIGHT HAVE ANTICIPATED THE POSSIBILITY OF, SUCH DAMAGES. 23 | 24 | **DRAFT OR NOT RATIFIED PROPOSALS** (REFER TO PROPOSAL STATUS AND/OR SUBMISSION STATUS ON COVER PAGE) ARE PROVIDED "AS IS" TO INTERESTED PARTIES FOR DISCUSSION ONLY. PARTIES THAT CHOOSE TO IMPLEMENT THIS DRAFT PROPOSAL DO SO AT THEIR OWN RISK. IT IS A DRAFT DOCUMENT AND MAY BE UPDATED, REPLACED, OR MADE OBSOLETE BY OTHER DOCUMENTS AT ANY TIME. THE FIX GLOBAL TECHNICAL COMMITTEE WILL NOT ALLOW EARLY IMPLEMENTATION TO CONSTRAIN ITS ABILITY TO MAKE CHANGES TO THIS SPECIFICATION PRIOR TO FINAL RELEASE. IT IS INAPPROPRIATE TO USE FIX WORKING DRAFTS AS REFERENCE MATERIAL OR TO CITE THEM AS OTHER THAN “WORKS IN PROGRESS”. THE FIX GLOBAL TECHNICAL COMMITTEE WILL ISSUE, UPON COMPLETION OF REVIEW AND RATIFICATION, AN OFFICIAL STATUS ("APPROVED") OF/FOR THE PROPOSAL AND A RELEASE NUMBER. 25 | 26 | No proprietary or ownership interest of any kind is granted with respect to the FIX Protocol (or any rights therein). 27 | 28 | Copyright 2013-2018 FIX Protocol Ltd., all rights reserved. 29 | 30 | 31 | FIX Performance Session Layer specification by [FIX Protocol Ltd.](http://www.fixtradingcommunity.org/) is licensed under a [Creative Commons Attribution-NoDerivatives 4.0 International License](http://creativecommons.org/licenses/by-nd/4.0/). 32 | Based on a work at . 33 | -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/01Introduction.md: -------------------------------------------------------------------------------- 1 | Introduction 2 | ============ 3 | 4 | FIX Performance Session Layer (FIXP) is a “lightweight point-to-point protocol” introduced to provide an open industry standard for high performance computing requirements currently encountered by the FIX Community. FIXP is a derived work. The origin and basis for FIXP are the FIX session layer protocols and the designed and implemented by NASDAQOMX, SoupTCP, SoupBinTCP, and UFO (UDP for Orders). Every attempt was made to keep FIXP as close to the functionality and behavior of SoupBinTCP and UFO as possible. Extensions and refactoring were performed as incremental improvements. Every attempt was made to limit the FIXP to establishing and maintaining a communication session between two end points in a reliable manner, regardless of the reliability of the underlying transport. 5 | 6 | FIXP features 7 | 8 | - Binary protocol 9 | 10 | - Very simple lightweight point-to-point session layer for reliable communication. 11 | 12 | - Communication protocol independent 13 | 14 | - Encoding independent 15 | 16 | - Restricted to initiating, maintaining, and reestablishing a session. 17 | 18 | 19 | Authors 20 | ------- 21 | 22 | | Name | Affiliation | Contact | Role 23 | |-----------------|-------------------------|------------------------------|--------------------------------------------------------------------------------------| 24 | | Anders Furuhed | Goldman Sachs | | Protocol Designer 25 | | David Rosenborg | Goldman Sachs | | Protocol Designer 26 | | Rolf Andersson | Goldman Sachs | | Contributor 27 | | Jim Northey | LaSalle Technology | | Global Technical Committee co-chair 28 | | Júlio L R Monteiro | formerly B3 | | Editor, Working Group convener 29 | | Aditya Kapur | CME Group, Inc | | Contributor 30 | | Don Mendelson | Silver Flash LLC | | Working Group Lead | 31 | | Li Zhu | Shanghai Stock Exchange | | Contributor | 32 | 33 | 34 | ### Related FIX Standards 35 | 36 | The FIX Simple Open Framing Header standard governs how messages are delimited and has a specific relationship mentioned in this specification. FIXP interoperates with the other FIX standards at application and presentation layers, but it is not dependent on them. Therefore, they are considered non-normative for FIXP. 37 | 38 | | Related Standard | Version | Reference location | Relationship | Normative | 39 | |------------------------------|----------------|------------------------|--------------------------------------|---------------| 40 | | Simple Open Framing Header | Draft Standard | [SOFH](https://www.fixtrading.org/packages/fix-simple-open-framing-header-draft-standard-1-0/) | Optional usage at presentation layer | Yes | 41 | | FIX message specifications | 5.0 SP2 | [FIX 5.0 SP2](https://www.fixtrading.org/packages/fix-5-0-service-pack-2-specification-w-20110818-errata/) | Presentation and application layers | No | 42 | | FIX Simple Binary Encoding | Version 1.0 | [Simple Binary Encoding](https://www.fixtrading.org/packages/simple-binary-encoding-technical-specification-final/) | Optional usage at presentation layer | No | 43 | | Encoding FIX Using ASN.1 | Draft Standard | [ASN.1](https://www.fixtrading.org/packages/encoding-fix-using-asn-1-draft-standard/) | Optional usage at presentation layer | No | 44 | | Encoding FIX Using GPB | RC2 | [GPB](https://www.fixtrading.org/packages/encoding-fix-using-google-protocol-buffers-release-candidate-2/) | Optional usage at presentation layer | No | 45 | 46 | ### Dependencies on Other Specifications 47 | 48 | FIXP is dependent on several industry standards. Implementations of FIXP must conform to these standards to interoperate. Therefore, they are normative for FIXP. Other protocols may be used by agreement between counterparties. 49 | 50 | 51 | | Related Standard | Version | Reference location | Relationship | Normative | 52 | |--------------------------------------------------------------|-------------|--------------------------------------|---------------------------------|---------------| 53 | | RFC 793 Transmission Control Program (TCP) | N/A | and related standards | Uses transport | Yes | 54 | | RFC 768 User Datagram Protocol (UDP) | N/A | | Uses transport | Yes | 55 | | RFC4122 A Universally Unique Identifier (UUID) URN Namespace | N/A | | Uses | Yes | 56 | | UTF-8, a transformation format of ISO 10646 | N/A | | Uses encoding | Yes | 57 | | Various authentication protocols | N/A | | Optional usage at session layer | No | 58 | 59 | ## Specification terms 60 | 61 | These key words in this document are to be interpreted as described in 62 | [Internet Engineering Task Force RFC2119](http://www.apps.ietf.org/rfc/rfc2119.html). These terms indicate 63 | an absolute requirement for implementations of the standard: "**must**", 64 | or "**required**". 65 | 66 | This term indicates an absolute prohibition: "**must not**". 67 | 68 | These terms indicate that a feature is allowed by the standard but not 69 | required: "**may**", "**optional**". An implementation that does not 70 | provide an optional feature must be prepared to interoperate with one 71 | that does. 72 | 73 | These terms give guidance, recommendation or best practices: 74 | "**should**" or "**recommended**". A recommended choice among 75 | alternatives is described as "**preferred**". 76 | 77 | These terms give guidance that a practice is not recommended: "**should not**" 78 | or "**not recommended**". 79 | 80 | Definitions 81 | ----------- 82 | 83 | | Term | Definition | 84 | |---------|-------------| 85 | | Client | Initiator of session 86 | | Credentials | User identification for authentication 87 | | Flow | A unidirectional stream of messages. Each flow has one producer and one or more consumers. 88 | | Idempotence | Idempotence means that an operation that is applied multiple times does not change the outcome, the result, after the first time 89 | | Multicast | A method of sending datagrams from one producer to multiple consumers 90 | | IETF | Internet Engineering Task Force 91 | | Server | Acceptor of session 92 | | Session | A dialog for exchanging application messages between peers. An established point-to-point session consists of a pair of flows, one in each direction between peers. A multicast session consists of a single flow from the producer to multiple consumers. 93 | | TCP | Transmission Control Protocol is a set of IETF standards for a reliable stream of data exchanged between peers. Since it is connection oriented, it incorporates some features of a session protocol. 94 | | TLS | Transport Layer Security is a set of IETF standards to provide security to a session. TLS is a successor to Secure Sockets Layer (SSL). 95 | | UDP | User Datagram Protocol is a connectionless transmission for delivering packets of data. Any rules for a long-lived exchange of messages must be supplied by a session protocol. -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/02Requirements.md: -------------------------------------------------------------------------------- 1 | Requirements 2 | ============ 3 | 4 | Business Requirements 5 | --------------------- 6 | 7 | Create an enhanced session protocol that can provide reliable, highly efficient, exchange of messages to support high performance financial messaging, over a variety of transports. 8 | 9 | Protocol shall be fit for purpose for current high message rates, low latency environments in financial markets, but should be to every extent possible applicable to other business domains. There is no reason to limit or couple the session layer to the financial markets / trading business domain without extraordinary reason. 10 | 11 | Support common message flow types: Recoverable, Unsequenced, Idempotent (operations guaranteed to be applied only once), and None (for a one-way flow of messages). 12 | 13 | Protocol shall support asymmetric models, such as market participant to market, in addition to peer-to-peer (symmetric). Allow the communication of messages to multiple receivers (broadcast). 14 | 15 | The session protocol does not require or recommend a specific authentication protocol. Counterparties are free to agree on user authentication techniques that fit their needs. 16 | 17 | Technical Requirements 18 | ---------------------- 19 | 20 | ### Protocol Layering 21 | 22 | This standard endeavors to maintain a clear separation of protocol layers, as expressed by the Open Systems Interconnection model (OSI). The responsibilities of a session layer are establishment, termination and restart procedures and rules for the exchange of application messages. 23 | 24 | The protocol shall be independent of message encoding (presentation layer), to provide the maximum utility. Encoding independence applies both to session layer messages specified in this document as well as to application messages. It is simpler if session protocol messages are encoded the same way as application messages, but that is not a requirement of this session protocol. 25 | 26 | Users are free to specify message encodings by agreement with counterparties. FIX provides Simple Binary Encoding as well as mappings of FIX to other high performance encodings such as ASN.1, and Google Protocol Buffers. See the list of related standards above. Other recognized encodings may follow in the future. 27 | 28 | Of necessity, the session protocol makes some adaptations for transport layer protocols used by the session layer since the capabilities of common transports are quite different. In particular, TCP is connection- and stream-oriented and implements its own reliable delivery mechanisms. Meanwhile, UDP is datagram-oriented and does not guarantee delivery in order. Unfortunately, these characteristics bleed across protocol layers. 29 | 30 | ### Security Mechanisms 31 | 32 | FIXP does not specify its own security features. Rather, the FIX Trading Community separately issues security requirements and recommendations that may apply to FIXP 33 | and other FIX session protocols. Due to the ever-changing nature of information security, the requirements and recommendations are likely to be updated periodically. In general, it is recommended that FIX traffic be protected by using proven controls specified by the FIX Trading Community. 34 | 35 | The FIX Trading Community is in the process of specifying how to authenticate parties using TLS and optionally using FIX credentials. FIX credentials can be used to authenticate a client after an underlying TLS session has been established. FIXP supports this use case by providing a field for credentials in the FIXP session negotiation handshake. 36 | 37 | ### Low Overhead 38 | 39 | Minimum overhead is added to the messages exchanged between peers, using only the strictly necessary control messages. 40 | 41 | By agreement between counterparties, a message framing protocol may be used to delimit messages. This relieves the session layer of application message decoding to determine message boundaries. FIX offers the Simple Open Framing Header standard for framing messages encoded with binary wire formats. See standards references above. 42 | -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/05MulticastSessionProtocol.md: -------------------------------------------------------------------------------- 1 | Multicast Session Protocol 2 | ========================== 3 | 4 | A multicast session conveys messages one way from a publisher to any number of listeners. It is conducted over a connectionless transport such UDP multicast. Multicast session protocol is typically used for publishing market data or common reference information to many consumers. Multiple independent flows may be multiplexed over a shared multicast transport. 5 | 6 | Multicast Session Lifecycle 7 | --------------------------- 8 | 9 | Since a multicast transport is connectionless, there is no negotiation or binding or unbinding of the transport as in the point-to-point protocol. Thus, Negotiation and Establishment messages and their respective responses are not used. 10 | 11 | Multicast addresses and publishing schedules must be provided out-of-band to listeners. To capture all messages, listeners must be ready to receive at scheduled times. Publishing continues until the end of a logical flow. 12 | 13 | ### Multicast Session Establishment 14 | 15 | Like a point-to-point session, a multicast session is identified by a UUID. Each time a session is initiated, a new UUID must be generated, and sequence numbers of subsequent application messages must begin with 1. 16 | 17 | #### Topic Message 18 | 19 | To associate a transient UUID to a permanent or semi-permanent classification of messages, a Topic message must be used to initiate a flow. Multiple topics may be published on a transport. 20 | 21 | FlowType = Recoverable | Idempotent 22 | 23 | Valid flow types on a multicast session are: 24 | 25 | - **Recoverable**: Messages are sequenced and recoverable. Since the transport is one-way, RetransmitRequests must be delivered through a separate session, however. 26 | 27 | - **Idempotent**: Messages are sequenced to allow detection of loss but any missed messages are not recoverable. 28 | 29 | Each Topic carries a Classification for the flow to associate it to a permanent or semi-permanent application layer entity. Typical classifications are product types, market symbols or the like. 30 | 31 | To support late joiners, Topic messages should be repeated at regular intervals on a session. This specification does not dictate a specific interval, but the shorter the interval, the less time it takes for a late joiner to identify flows. It is recommended that Topic message be sent with Session heartbeats when the session is otherwise idle. See session heartbeat section below. 32 | 33 | **Topic** 34 | 35 | | **Field name** | **Type** | **Required** | **Value** | **Description** | 36 | |----------------|----------|--------------|-----------|-----------------| 37 | | MessageType | Enum | Y | Topic | | 38 | | SessionId | UUID | Y | | Session Identifier 39 | | Flow | FlowType Enum | Y | | Type of flow from publisher 40 | | Classification | Object | Y | | Category of application messages that follow 41 | 42 | ### Finalizing a Multicast Session 43 | 44 | Finalization ends a logical flow when there are no more application messages to send. A multicast flow should be finalized by transmitting a FinishedSending message. No further messages should be sent, and the session ID is no longer valid after that. 45 | 46 | Idempotent Flow over Multicast 47 | ------------------------------ 48 | The goal of an idempotent flow over multicast is to provide at-most-once delivery guarantee to each consumer. Unlike a point-to-point session, however, there is no opportunity to return a NotApplied message to the producer over a one-way transport if a sequence number gap is detected. Therefore, on a multicast, an idempotent flow provides a means to detect data loss, but no direct way to notify the producer or initiate recovery. 49 | 50 | An idempotent flow is implemented by the producer in the same way over a multicast transport as for point-to-point over UDP unicast. Each datagram must begin with either a Sequence message if non-multiplexed or a Context message if the flow is sent over a multiplexed transport. 51 | 52 | Session Heartbeat 53 | ----------------- 54 | 55 | During the lifetime of a multicast session, its publisher should send Sequence or Context messages as a heartbeat at regular intervals when the session is otherwise inactive. This allows a receiver to tell whether a session is live and has not reached the end of its logical flow. If only a single Topic is published, then Sequence message may be used for heartbeats since there is no context switch. If multiple topics are published on a shared multicast transport, then Context must be used. See the Common Features section above for a description of sequence numbering and the Sequence and Context messages. 56 | 57 | In addition to the Sequence or Context message, it is recommended that a Topic message should be published on the heartbeat interval. This provides an opportunity for late joiners to gather session characteristics during every idle period. -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/06SummaryOfSessionMessages.md: -------------------------------------------------------------------------------- 1 | Summary of Session Messages 2 | =========================== 3 | 4 | FIXP Session Messages 5 | --------------------- 6 | 7 | | Stage | Message Name | Purpose | Recoverable | Idempotent | Unsequenced / None | Multicast | 8 | |----------------|----------------------|----------------------------------------|:-------------:|:------------:|:------------------:|:---------:| 9 | | Initialization | Negotiate | Initiates session | • | • | • | | 10 | | | NegotiationResponse | Accepts session | • | • | • | | 11 | | | NegotiationReject | Rejects session | • | • | • | | 12 | | | Topic | Announces a flow | | | | • | 13 | | | MessageTemplate | Delivers template | • | • | • | • | 14 | | Binding | Establish | Binds session to transport | • | • | • | | 15 | | | EstablishmentAck | Accepts binding | • | • | • | | 16 | | | EstablishmentReject | Rejects binding | • | • | • | | 17 | | Transferring | Sequence | Initiates a sequenced flow, keep-alive | • | • | | • | 18 | | | Context | Multiplexing | • | • | • | • | 19 | | | UnsequencedHeartbeat | Keep-alive | | | • | | 20 | | | RetransmitRequest | Requests resynchronization | • | | | | 21 | | | Retransmission | Resynchronization | • | | | | 22 | | Unbinding | Terminate | Unbinds a transport | • | • | • | | 23 | | Finalizing | FinishedSending | Ends a logical flow | • | • | • | • | 24 | | | FinishedReceiving | Ends a logical flow | • | • | • | • | 25 | 26 | Related Application Messages 27 | ---------------------------- 28 | 29 | These optional application messages respond to application messages on an idempotent flow. 30 | 31 | | Stage | Message Name | Purpose | 32 | |--------------|--------------|---------------------------------------------------| 33 | | Transferring | Applied | Acknowledge idempotent operations | 34 | | | NotApplied | Negative acknowledgement of idempotent operations | 35 | 36 | Summary of Protocol Violations 37 | ------------------------------ 38 | 39 | If any of these violations by a peer is detected, the session should be immediately terminated. Any application messages that cause a violation, such as a message sent after FinishedSending, should be ignored. 40 | 41 | - Sending a session message that is inappropriate to the flow type, such as a Sequence message on an unsequenced flow. See table above. 42 | - Sending an application message on a point-to-point session that is not in established state. That is, prior to EstablishmentAck. 43 | - Sending Establish without having successfully negotiated a session. That is, a NegotiationResponse must have been received for the session. 44 | - Sending an application message after logical flow has been finalized with FinishedSending. The responder on a point-to-point session may not send an application message after sending FinishedReceiving. 45 | - Sending FinishedReceiving without having received FinishedSending from the peer. 46 | - Sending any application or session message after sending Terminate. 47 | - Reusing the session ID of a session that was finalized. (The server may have a practical limit of session history to enforce this rule.) 48 | - Sending a RetransmitRequest while a retransmission is in progress. 49 | - Sending a RetransmitRequest with request range out of bounds. That is, it is a violation to request a retransmission of a message with a sequence number that has not been sent yet. 50 | 51 | -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/08RulesOfEngagement.md: -------------------------------------------------------------------------------- 1 | Appendix B – FIXP Rules of Engagement 2 | ===================================== 3 | 4 | This checklist is an aid to specifying a full protocol stack to be used for communication between counterparties 5 | 6 | | Stack layer | Client | Server | 7 | |---------------------------------------|----------------------------|-------------| 8 | | **Application Layer** | | | 9 | | Application level recovery supported? | | | 10 | | FIX version | | | 11 | | Service pack | | | 12 | | Extension packs | | | 13 | | **Presentation Layer** | | | 14 | | Message encoding | | | 15 | | Version | | | 16 | | Schema/templates | | | 17 | | Framing | | | 18 | | **Session Layer** | | | 19 | | Supported flow types | | | 20 | | **Security protocols** | | | 21 | | TLS version | | 22 | | Authentication | | | 23 | | Cipher suites | | | 24 | | **Transport Layer** | | | 25 | | Transports supported | | | 26 | | Other network protocols | | | -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/FIXDisclaimerTechStd.md: -------------------------------------------------------------------------------- 1 | ::: {custom-style=Disclaimer} 2 | DISCLAIMER 3 | ::: 4 | 5 | THE INFORMATION CONTAINED HEREIN AND THE FINANCIAL INFORMATION EXCHANGE PROTOCOL (COLLECTIVELY, THE "FIX PROTOCOL") ARE PROVIDED "AS IS" AND NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL MAKES ANY REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED, AS TO THE FIX PROTOCOL (OR THE RESULTS TO BE OBTAINED BY THE USE THEREOF) OR ANY OTHER MATTER AND EACH SUCH PERSON AND ENTITY SPECIFICALLY DISCLAIMS ANY WARRANTY OF ORIGINALITY, ACCURACY, COMPLETENESS, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SUCH PERSONS AND ENTITIES DO NOT WARRANT THAT THE FIX PROTOCOL WILL CONFORM TO ANY DESCRIPTION THEREOF OR BE FREE OF ERRORS. THE ENTIRE RISK OF ANY USE OF THE FIX PROTOCOL IS ASSUMED BY THE USER. 6 | 7 | NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL SHALL HAVE ANY LIABILITY FOR DAMAGES OF ANY KIND ARISING IN ANY MANNER OUT OF OR IN CONNECTION WITH ANY USER'S USE OF (OR ANY INABILITY TO USE) THE FIX PROTOCOL, WHETHER DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL (INCLUDING, WITHOUT LIMITATION, LOSS OF DATA, LOSS OF USE, CLAIMS OF THIRD PARTIES OR LOST PROFITS OR REVENUES OR OTHER ECONOMIC LOSS), WHETHER IN TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), CONTRACT OR OTHERWISE, WHETHER OR NOT ANY SUCH PERSON OR ENTITY HAS BEEN ADVISED OF, OR OTHERWISE MIGHT HAVE ANTICIPATED THE POSSIBILITY OF, SUCH DAMAGES. 8 | 9 | **DRAFT OR NOT RATIFIED PROPOSALS** (REFER TO PROPOSAL STATUS AND/OR SUBMISSION STATUS ON COVER PAGE) ARE PROVIDED "AS IS" TO INTERESTED 10 | PARTIES FOR DISCUSSION ONLY. PARTIES THAT CHOOSE TO IMPLEMENT THIS DRAFT PROPOSAL DO SO AT THEIR OWN RISK. IT IS A DRAFT DOCUMENT AND MAY BE 11 | UPDATED, REPLACED, OR MADE OBSOLETE BY OTHER DOCUMENTS AT ANY TIME. THE FIX GLOBAL TECHNICAL COMMITTEE WILL NOT ALLOW EARLY IMPLEMENTATION TO 12 | CONSTRAIN ITS ABILITY TO MAKE CHANGES TO THIS SPECIFICATION PRIOR TO FINAL RELEASE. IT IS INAPPROPRIATE TO USE FIX WORKING DRAFTS AS 13 | REFERENCE MATERIAL OR TO CITE THEM AS OTHER THAN “WORKS IN PROGRESS”. THE FIX GLOBAL TECHNICAL COMMITTEE WILL ISSUE, UPON COMPLETION OF REVIEW 14 | AND RATIFICATION, AN OFFICIAL STATUS ("APPROVED") OF/FOR THE PROPOSAL AND A RELEASE NUMBER. 15 | 16 | No proprietary or ownership interest of any kind is granted with respect to the FIX Protocol (or any rights therein), except as expressly set out in FIX Protocol Limited's Copyright and Acceptable Use Policy. 17 | 18 | © Copyright 2011-2018 FIX Protocol Limited, all rights reserved 19 | 20 | \ 21 | 22 | ![](https://i.creativecommons.org/l/by-nd/4.0/88x31.png) 23 | 24 | FIX Technical Standard Specifications by [FIX Protocol Ltd.](https://www.fixtradingcommunity.org/) are licensed under a [Creative Commons Attribution-NoDerivatives 4.0 International License](http://creativecommons.org/licenses/by-nd/4.0/). Based on a work at [https://github.com/FIXTradingCommunity/](https://github.com/FIXTradingCommunity/). 25 | 26 | 27 | 1. 28 | -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/FIXP.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | echo Compilation started... 4 | # Script is expected to start running in the folder where it is located (together with the source files) 5 | SOURCE="$PWD" 6 | # There is only one disclaimer and style docx file for all FIX Technical Standards and it is stored with the FIX Session Layer 7 | # FIXP Repository has local copies with the specific names and dates of the standard 8 | DISCLAIMER="FIXDisclaimerTechStd.md" 9 | STYLE="FIX_TechStd_Style_MASTER.docx" 10 | TARGET="$SOURCE/target" 11 | YAML="$SOURCE/FIXP.yaml" 12 | FILES="01Introduction.md 02Requirements.md 03CommonFeatures.md 04PointToPointSessionProtocol.md 05MulticastSessionProtocol.md 06SummaryOfSessionMessages.md 07UsageExamples.md 08RulesOfEngagement.md" 13 | WPFOLDER="/wp-content/uploads/2020/03/" 14 | 15 | # Create document version with disclaimer 16 | pandoc "$DISCLAIMER" $FILES -o "$TARGET/docx/FIX Performance Session Layer V1.0.docx" --reference-doc="$STYLE" --metadata-file="$YAML" --toc --toc-depth=4 17 | echo FIXP document version created 18 | 19 | # Create base online version without disclaimer 20 | pandoc $FILES -s -o "$TARGET/debug/FIXPONLINE.html" -s --metadata-file="$YAML" --toc --toc-depth=2 21 | 22 | # Create separate online versions for production and test website by including appropriate link prefixes 23 | sed 's,img src="media/,img src="https://www.fixtrading.org'$WPFOLDER',g' "$TARGET/debug/FIXPONLINE.html" > "$TARGET/html/FIXPONLINE_PROD.html" 24 | sed s/www.fixtrading.org/www.technical-fixprotocol.org/ "$TARGET/html/FIXPONLINE_PROD.html" > "$TARGET/html/FIXPONLINE_TEST.html" 25 | echo FIXP ONLINE version created for PROD and TEST 26 | 27 | echo Compilation ended! 28 | -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/FIXP.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | title: FIX Performance Session Layer (FIXP) 3 | subtitle: Technical Specification 4 | author: 5 | - "Version 1.0 -- Draft Standard -- August 8, 2018" 6 | - "\x0D" 7 | - "THIS DOCUMENT IS A DRAFT STANDARD FOR A PROPOSED FIX TECHNICAL STANDARD. A DRAFT STANDARD" 8 | - "HAS BEEN APPROVED BY THE GLOBAL TECHNICAL COMMITTEE AS THE FINAL STEP IN CREATING A NEW FIX" 9 | - "TECHNICAL STANDARD. POTENTIAL ADOPTERS ARE STRONGLY ENCOURAGED TO BEGIN WORKING WITH" 10 | - "THE DRAFT STANDARD AND TO PROVIDE FEEDBACK TO THE GLOBAL TECHNICAL COMMITTEE AND THE" 11 | - "WORKING GROUP THAT SUBMITTED THE PROPOSAL. THE FEEDBACK TO THE DRAFT STANDARD WILL" 12 | - "DETERMINE WHEN TWO INTEROPERABLE IMPLEMENTATIONS HAVE BEEN ESTABLISHED AND THE DRAFT" 13 | - "STANDARD CAN BE PROMOTED TO BECOME A NEW FIX TECHNICAL STANDARD." 14 | --- 15 | -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/FIX_TechStd_Style_MASTER.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-DRAFT/doc/FIX_TechStd_Style_MASTER.docx -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/media/FlowFinalization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-DRAFT/doc/media/FlowFinalization.png -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/media/Idempotent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-DRAFT/doc/media/Idempotent.png -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/media/Retransmission.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-DRAFT/doc/media/Retransmission.png -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/media/RetransmissionReject.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-DRAFT/doc/media/RetransmissionReject.png -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/media/RetransmitViolation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-DRAFT/doc/media/RetransmitViolation.png -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/media/SessionEstablishment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-DRAFT/doc/media/SessionEstablishment.png -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/media/SessionNegotiation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-DRAFT/doc/media/SessionNegotiation.png -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/media/UnbindTransport-TCP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-DRAFT/doc/media/UnbindTransport-TCP.png -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/media/UnbindTransport-UDP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-DRAFT/doc/media/UnbindTransport-UDP.png -------------------------------------------------------------------------------- /v1-0-DRAFT/doc/media/image1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-DRAFT/doc/media/image1.jpeg -------------------------------------------------------------------------------- /v1-0-DRAFT/resources/SBEschemaForFIXP.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 0 19 | 1 20 | 2 21 | 3 22 | 23 | 24 | 0 25 | 1 26 | 2 27 | 3 28 | 29 | 30 | 0 31 | 1 32 | 2 33 | 3 34 | 4 35 | 5 36 | 37 | 38 | 0 39 | 1 40 | 2 41 | 42 | 43 | 0 44 | 1 45 | 2 46 | 3 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | -------------------------------------------------------------------------------- /v1-0-RC2/doc/00Contents.md: -------------------------------------------------------------------------------- 1 | Contents 2 | ======== 3 | 4 | [Title](00Title.md) 5 | 6 | [1. Introduction](01Introduction.md) 7 | 8 | [2. Requirements](02Requirements.md) 9 | 10 | [3. Common Features](03CommonFeatures.md) 11 | 12 | [4. Point to Point Session Protocol](04PointToPointSessionProtocol.md) 13 | 14 | [5. Multicast Session Protocol](05MulticastSessionProtocol.md) 15 | 16 | [6. Summary of Session Messages](06SummaryOfSessionMessages.md) 17 | 18 | [7. Appendix A: Usage Examples](07UsageExamples.md) 19 | 20 | [8. Appendix B: Rules of Engagement](08RulesOfEngagement.md) -------------------------------------------------------------------------------- /v1-0-RC2/doc/00Title.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC2/doc/00Title.md -------------------------------------------------------------------------------- /v1-0-RC2/doc/02Requirements.md: -------------------------------------------------------------------------------- 1 | Requirements 2 | ============ 3 | 4 | Business Requirements 5 | --------------------- 6 | 7 | Create an enhanced session protocol that can provide reliable, highly efficient, exchange of messages to support high performance financial messaging, over a variety of transports. 8 | 9 | Protocol shall be fit for purpose for current high message rates, low latency environments in financial markets, but should be to every extent possible applicable to other business domains. There is no reason to limit or couple the session layer to the financial markets / trading business domain without extraordinary reason. 10 | 11 | Support common message flow types: Recoverable, Unsequenced, Idempotent (operations guaranteed to be applied only once), and None (for a one-way flow of messages). 12 | 13 | Protocol shall support asymmetric models, such as market participant to market, in addition to peer-to-peer (symmetric). Allow the communication of messages to multiple receivers (broadcast). 14 | 15 | The session protocol does not require or recommend a specific authentication protocol. Counterparties are free to agree on user authentication techniques that fit their needs. 16 | 17 | Technical Requirements 18 | ---------------------- 19 | 20 | ### Protocol Layering 21 | 22 | This standard endeavors to maintain a clear separation of protocol layers, as expressed by the Open Systems Interconnection model (OSI). The responsibilities of a session layer are establishment, termination and restart procedures and rules for the exchange of application messages. 23 | 24 | The protocol shall be independent of message encoding (presentation layer), to provide the maximum utility. Encoding independence applies both to session layer messages specified in this document as well as to application messages. It is simpler if session protocol messages are encoded the same way as application messages, but that is not a requirement of this session protocol. 25 | 26 | Users are free to specify message encodings by agreement with counterparties. FIX provides Simple Binary Encoding as well as mappings of FIX to other high performance encodings such as ASN.1, and Google Protocol Buffers. See the list of related standards above. Other recognized encodings may follow in the future. 27 | 28 | Of necessity, the session protocol makes some adaptations for transport layer protocols used by the session layer since the capabilities of common transports are quite different. In particular, TCP is connection- and stream-oriented and implements its own reliable delivery mechanisms. Meanwhile, UDP is datagram-oriented and does not guarantee delivery in order. Unfortunately, these characteristics bleed across protocol layers. 29 | 30 | ### Security Mechanisms 31 | 32 | FIXP does not specify security features for user authentication or privacy. If such features are desired, it is recommended that proven mechanisms be employed in other protocol layers, such as a secure transport. 33 | 34 | ### Low Overhead 35 | 36 | Minimum overhead is added to the messages exchanged between peers, using only the strictly necessary control messages. 37 | 38 | By agreement between counterparties, a message framing protocol may be used to delimit messages. This relieves the session layer of application message decoding to determine message boundaries. FIX offers the Simple Open Framing Header standard for framing messages encoded with binary wire formats. See standards references above. 39 | -------------------------------------------------------------------------------- /v1-0-RC2/doc/05MulticastSessionProtocol.md: -------------------------------------------------------------------------------- 1 | Multicast Session Protocol 2 | ========================== 3 | 4 | A multicast session conveys messages one way from a publisher to any number of listeners. It is conducted over a connectionless transport such UDP multicast. Multicast session protocol is typically used for publishing market data or common reference information to many consumers. Multiple independent flows may be multiplexed over a shared multicast transport. 5 | 6 | Multicast Session Lifecycle 7 | --------------------------- 8 | 9 | Since a multicast transport is connectionless, there is no negotiation or binding or unbinding of the transport as in the point-to-point protocol. Thus, Negotiation and Establishment messages and their respective responses are not used. 10 | 11 | Multicast addresses and publishing schedules must be provided out-of-band to listeners. To capture all messages, listeners must be ready to receive at scheduled times. Publishing continues until the end of a logical flow. 12 | 13 | ### Multicast Session Establishment 14 | 15 | Like a point-to-point session, a multicast session is identified by a UUID. Each time a session is initiated, a new UUID should be generated, and sequence numbers of subsequent application messages begin with 1. 16 | 17 | #### Topic Message 18 | 19 | To associate a transient UUID to a permanent or semi-permanent classification of messages, a Topic message is used to initiate a flow. Multiple topics may be published on a transport. 20 | 21 | FlowType = Recoverable | Idempotent 22 | 23 | Valid flow types on a multicast session are: 24 | 25 | - **Recoverable**: Messages are sequenced and recoverable. Since the transport is one-way, RetransmitRequests must be delivered through a separate session, however. 26 | 27 | - **Idempotent**: Messages are sequenced to allow detection of loss but any missed messages are not recoverable. 28 | 29 | Each Topic carries a Classification for the flow to associate it to a permanent or semi-permanent application layer entity. Typical classifications are product types, market symbols or the like. 30 | 31 | To support late joiners, Topic messages should be repeated at regular intervals on a session. This specification does not dictate a specific interval, but the shorter the interval, the less time it takes for a late joiner to identify flows. 32 | 33 | **Topic** 34 | 35 | | **Field name** | **Type** | **Required** | **Value** | **Description** | 36 | |----------------|----------|--------------|-----------|-----------------| 37 | | MessageType | Enum | Y | Topic | | 38 | | SessionId | UUID | Y | | Session Identifier 39 | | Flow | FlowType Enum | Y | | Type of flow from publisher 40 | | Classification | Object | Y | | Category of application messages that follow 41 | 42 | ### Finalizing a Multicast Session 43 | 44 | Finalization ends a logical flow when there are no more application messages to send. A multicast flows is finalized by transmitting a FinishedSending message. No further messages may be sent, and the session ID is no longer valid after that. 45 | 46 | Session Heartbeat 47 | ----------------- 48 | 49 | During the lifetime of a multicast session, its publisher should send Sequence or Context messages as a heartbeat at regular intervals when the session is otherwise inactive. This allows a receiver to tell whether a session is live and has not reached the end of its logical flow. 50 | 51 | See the section Sequence above for a description of sequence numbering and the Sequence message. -------------------------------------------------------------------------------- /v1-0-RC2/doc/06SummaryOfSessionMessages.md: -------------------------------------------------------------------------------- 1 | Summary of Session Messages 2 | =========================== 3 | 4 | FIXP Session Messages 5 | --------------------- 6 | 7 | | Stage | Message Name | Purpose | Recoverable | Idempotent | Unsequenced / None | Multicast | 8 | |----------------|----------------------|----------------------------------------|:-------------:|:------------:|:------------------:|:---------:| 9 | | Initialization | Negotiate | Initiates session | • | • | • | | 10 | | | NegotiationResponse | Accepts session | • | • | • | | 11 | | | NegotiationReject | Rejects session | • | • | • | | 12 | | | Topic | Announces a flow | | | | • | 13 | | Binding | Establish | Binds session to transport | • | • | • | | 14 | | | EstablishmentAck | Accepts binding | • | • | • | | 15 | | | EstablishmentReject | Rejects binding | • | • | • | | 16 | | Transferring | Sequence | Initiates a sequenced flow, keep-alive | • | • | | • | 17 | | | Context | Multiplexing | • | • | • | • | 18 | | | UnsequencedHeartbeat | Keep-alive | | | • | | 19 | | | RetransmitRequest | Requests resynchronization | • | | | | 20 | | | Retransmission | Resynchronization | • | | | | 21 | | Unbinding | Terminate | Unbinds a transport | • | • | • | | 22 | | Finalizing | FinishedSending | Ends a logical flow | • | • | • | • | 23 | | | FinishedReceiving | Ends a logical flow | • | • | • | • | 24 | 25 | Related Application Messages 26 | ---------------------------- 27 | 28 | These optional application messages respond to application messages on an idempotent flow. 29 | 30 | | Stage | Message Name | Purpose | 31 | |--------------|--------------|---------------------------------------------------| 32 | | Transferring | Applied | Acknowledge idempotent operations | 33 | | | NotApplied | Negative acknowledgement of idempotent operations | 34 | 35 | Summary of Protocol Violations 36 | ------------------------------ 37 | 38 | If any of these violations by a peer is detected, the session should be terminated. 39 | 40 | - Sending a session message that is inappropriate to the flow type, such as a Sequence message on an unsequenced flow. See table above. 41 | 42 | - *Sending an application message on a session that is not in established state.* 43 | 44 | - *Reusing the session ID of a session that was finalized.* 45 | 46 | - Sending a RetransmitRequest while a retransmission is in progress. 47 | 48 | - *Sending a RetransmitRequest with request range out of bounds. That is, it is a violation to request a retransmission of a message with a sequence number that has not been sent yet.* 49 | -------------------------------------------------------------------------------- /v1-0-RC2/doc/08RulesOfEngagement.md: -------------------------------------------------------------------------------- 1 | Appendix B – FIXP Rules of Engagement 2 | ===================================== 3 | 4 | This checklist is an aid to specifying a full protocol stack to be used for communication between counterparties 5 | 6 | | Stack layer | Client | Server | 7 | |---------------------------------------|----------------------------|-------------| 8 | | **Application Layer** | | | 9 | | Application level recovery supported? | | | 10 | | FIX version | | | 11 | | Service pack | | | 12 | | Extension packs | | | 13 | | **Presentation Layer** | | | 14 | | Message encoding | | | 15 | | Version | | | 16 | | Schema/templates | | | 17 | | Framing | | | 18 | | **Session Layer** | | | 19 | | Supported flow types | | | 20 | | **Security protocols** | | | 21 | | Authentication | | | 22 | | **Transport Layer** | | | 23 | | Transports supported | | | 24 | | Other network protocols | | | -------------------------------------------------------------------------------- /v1-0-RC2/doc/media/FlowFinalization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC2/doc/media/FlowFinalization.png -------------------------------------------------------------------------------- /v1-0-RC2/doc/media/Idempotent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC2/doc/media/Idempotent.png -------------------------------------------------------------------------------- /v1-0-RC2/doc/media/Retransmission.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC2/doc/media/Retransmission.png -------------------------------------------------------------------------------- /v1-0-RC2/doc/media/RetransmissionReject.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC2/doc/media/RetransmissionReject.png -------------------------------------------------------------------------------- /v1-0-RC2/doc/media/RetransmitViolation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC2/doc/media/RetransmitViolation.png -------------------------------------------------------------------------------- /v1-0-RC2/doc/media/SessionEstablishment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC2/doc/media/SessionEstablishment.png -------------------------------------------------------------------------------- /v1-0-RC2/doc/media/SessionNegotiation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC2/doc/media/SessionNegotiation.png -------------------------------------------------------------------------------- /v1-0-RC2/doc/media/UnbindTransport-TCP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC2/doc/media/UnbindTransport-TCP.png -------------------------------------------------------------------------------- /v1-0-RC2/doc/media/UnbindTransport-UDP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC2/doc/media/UnbindTransport-UDP.png -------------------------------------------------------------------------------- /v1-0-RC2/doc/media/image1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC2/doc/media/image1.jpeg -------------------------------------------------------------------------------- /v1-0-RC3/doc/00Contents.md: -------------------------------------------------------------------------------- 1 | Contents 2 | ======== 3 | 4 | [Title](00Title.md) 5 | 6 | [1. Introduction](01Introduction.md) 7 | 8 | [2. Requirements](02Requirements.md) 9 | 10 | [3. Common Features](03CommonFeatures.md) 11 | 12 | [4. Point to Point Session Protocol](04PointToPointSessionProtocol.md) 13 | 14 | [5. Multicast Session Protocol](05MulticastSessionProtocol.md) 15 | 16 | [6. Summary of Session Messages](06SummaryOfSessionMessages.md) 17 | 18 | [7. Appendix A: Usage Examples](07UsageExamples.md) 19 | 20 | [8. Appendix B: Rules of Engagement](08RulesOfEngagement.md) -------------------------------------------------------------------------------- /v1-0-RC3/doc/00Title.md: -------------------------------------------------------------------------------- 1 | ![](./media/image1.jpeg) 2 | 3 | FIX Performance Session Layer 4 | ============================= 5 | Technical Specification 6 | 7 | Release Candidate 3 8 | 9 | September 30, 2015 10 | 11 | **THIS DOCUMENT IS A RELEASE CANDIDATE FOR A PROPOSED FIX TECHNICAL 12 | STANDARD. A RELEASE CANDIDATE HAS BEEN APPROVED BY THE GLOBAL TECHNICAL 13 | COMMITTEE AS AN INITIAL STEP IN CREATING A NEW FIX TECHNICAL STANDARD. 14 | POTENTIAL ADOPTERS ARE STRONGLY ENCOURAGED TO BEGIN WORKING WITH THE 15 | RELEASE CANDIDATE AND TO PROVIDE FEEDBACK TO THE GLOBAL TECHNICAL 16 | COMMITTEE AND THE WORKING GROUP THAT SUBMITTED THE PROPOSAL. THE 17 | FEEDBACK TO THE RELEASE CANDIDATE WILL DETERMINE IF ANOTHER REVISION AND 18 | RELEASE CANDIDATE IS NECESSARY OR IF THE RELEASE CANDIDATE CAN BE 19 | PROMOTED TO BECOME A FIX TECHNICAL STANDARD DRAFT.** 20 | 21 | � Copyright 2014-2015 FIX Protocol Limited -------------------------------------------------------------------------------- /v1-0-RC3/doc/02Requirements.md: -------------------------------------------------------------------------------- 1 | Requirements 2 | ============ 3 | 4 | Business Requirements 5 | --------------------- 6 | 7 | Create an enhanced session protocol that can provide reliable, highly efficient, exchange of messages to support high performance financial messaging, over a variety of transports. 8 | 9 | Protocol shall be fit for purpose for current high message rates, low latency environments in financial markets, but should be to every extent possible applicable to other business domains. There is no reason to limit or couple the session layer to the financial markets / trading business domain without extraordinary reason. 10 | 11 | Support common message flow types: Recoverable, Unsequenced, Idempotent (operations guaranteed to be applied only once), and None (for a one-way flow of messages). 12 | 13 | Protocol shall support asymmetric models, such as market participant to market, in addition to peer-to-peer (symmetric). Allow the communication of messages to multiple receivers (broadcast). 14 | 15 | The session protocol does not require or recommend a specific authentication protocol. Counterparties are free to agree on user authentication techniques that fit their needs. 16 | 17 | Technical Requirements 18 | ---------------------- 19 | 20 | ### Protocol Layering 21 | 22 | This standard endeavors to maintain a clear separation of protocol layers, as expressed by the Open Systems Interconnection model (OSI). The responsibilities of a session layer are establishment, termination and restart procedures and rules for the exchange of application messages. 23 | 24 | The protocol shall be independent of message encoding (presentation layer), to provide the maximum utility. Encoding independence applies both to session layer messages specified in this document as well as to application messages. It is simpler if session protocol messages are encoded the same way as application messages, but that is not a requirement of this session protocol. 25 | 26 | Users are free to specify message encodings by agreement with counterparties. FIX provides Simple Binary Encoding as well as mappings of FIX to other high performance encodings such as ASN.1, and Google Protocol Buffers. See the list of related standards above. Other recognized encodings may follow in the future. 27 | 28 | Of necessity, the session protocol makes some adaptations for transport layer protocols used by the session layer since the capabilities of common transports are quite different. In particular, TCP is connection- and stream-oriented and implements its own reliable delivery mechanisms. Meanwhile, UDP is datagram-oriented and does not guarantee delivery in order. Unfortunately, these characteristics bleed across protocol layers. 29 | 30 | ### Security Mechanisms 31 | 32 | FIXP does not specify security features for user authentication or privacy. If such features are desired, it is recommended that proven mechanisms be employed in other protocol layers, such as a secure transport. 33 | 34 | ### Low Overhead 35 | 36 | Minimum overhead is added to the messages exchanged between peers, using only the strictly necessary control messages. 37 | 38 | By agreement between counterparties, a message framing protocol may be used to delimit messages. This relieves the session layer of application message decoding to determine message boundaries. FIX offers the Simple Open Framing Header standard for framing messages encoded with binary wire formats. See standards references above. 39 | -------------------------------------------------------------------------------- /v1-0-RC3/doc/05MulticastSessionProtocol.md: -------------------------------------------------------------------------------- 1 | Multicast Session Protocol 2 | ========================== 3 | 4 | A multicast session conveys messages one way from a publisher to any number of listeners. It is conducted over a connectionless transport such UDP multicast. Multicast session protocol is typically used for publishing market data or common reference information to many consumers. Multiple independent flows may be multiplexed over a shared multicast transport. 5 | 6 | Multicast Session Lifecycle 7 | --------------------------- 8 | 9 | Since a multicast transport is connectionless, there is no negotiation or binding or unbinding of the transport as in the point-to-point protocol. Thus, Negotiation and Establishment messages and their respective responses are not used. 10 | 11 | Multicast addresses and publishing schedules must be provided out-of-band to listeners. To capture all messages, listeners must be ready to receive at scheduled times. Publishing continues until the end of a logical flow. 12 | 13 | ### Multicast Session Establishment 14 | 15 | Like a point-to-point session, a multicast session is identified by a UUID. Each time a session is initiated, a new UUID must be generated, and sequence numbers of subsequent application messages must begin with 1. 16 | 17 | #### Topic Message 18 | 19 | To associate a transient UUID to a permanent or semi-permanent classification of messages, a Topic message must be used to initiate a flow. Multiple topics may be published on a transport. 20 | 21 | FlowType = Recoverable | Idempotent 22 | 23 | Valid flow types on a multicast session are: 24 | 25 | - **Recoverable**: Messages are sequenced and recoverable. Since the transport is one-way, RetransmitRequests must be delivered through a separate session, however. 26 | 27 | - **Idempotent**: Messages are sequenced to allow detection of loss but any missed messages are not recoverable. 28 | 29 | Each Topic carries a Classification for the flow to associate it to a permanent or semi-permanent application layer entity. Typical classifications are product types, market symbols or the like. 30 | 31 | To support late joiners, Topic messages should be repeated at regular intervals on a session. This specification does not dictate a specific interval, but the shorter the interval, the less time it takes for a late joiner to identify flows. It is recommended that Topic message be sent with Session heartbeats when the session is otherwise idle. See session heartbeat section below. 32 | 33 | **Topic** 34 | 35 | | **Field name** | **Type** | **Required** | **Value** | **Description** | 36 | |----------------|----------|--------------|-----------|-----------------| 37 | | MessageType | Enum | Y | Topic | | 38 | | SessionId | UUID | Y | | Session Identifier 39 | | Flow | FlowType Enum | Y | | Type of flow from publisher 40 | | Classification | Object | Y | | Category of application messages that follow 41 | 42 | ### Finalizing a Multicast Session 43 | 44 | Finalization ends a logical flow when there are no more application messages to send. A multicast flow should be finalized by transmitting a FinishedSending message. No further messages should be sent, and the session ID is no longer valid after that. 45 | 46 | Session Heartbeat 47 | ----------------- 48 | 49 | During the lifetime of a multicast session, its publisher should send Sequence or Context messages as a heartbeat at regular intervals when the session is otherwise inactive. This allows a receiver to tell whether a session is live and has not reached the end of its logical flow. If only a single Topic is published, then Sequence message may be used for heartbeats since there is no context switch. If multiple topics are published on a shared multicast transport, then Context must be used. See the Common Features section above for a description of sequence numbering and the Sequence and Context messages. 50 | 51 | In addition to the Sequence or Context message, it is recommend that a Topic message should be published on the heartbeat interval. This provides an opportunity for late joiners to gather session characteristics during every idle period. -------------------------------------------------------------------------------- /v1-0-RC3/doc/06SummaryOfSessionMessages.md: -------------------------------------------------------------------------------- 1 | Summary of Session Messages 2 | =========================== 3 | 4 | FIXP Session Messages 5 | --------------------- 6 | 7 | | Stage | Message Name | Purpose | Recoverable | Idempotent | Unsequenced / None | Multicast | 8 | |----------------|----------------------|----------------------------------------|:-------------:|:------------:|:------------------:|:---------:| 9 | | Initialization | Negotiate | Initiates session | • | • | • | | 10 | | | NegotiationResponse | Accepts session | • | • | • | | 11 | | | NegotiationReject | Rejects session | • | • | • | | 12 | | | Topic | Announces a flow | | | | • | 13 | | Binding | Establish | Binds session to transport | • | • | • | | 14 | | | EstablishmentAck | Accepts binding | • | • | • | | 15 | | | EstablishmentReject | Rejects binding | • | • | • | | 16 | | Transferring | Sequence | Initiates a sequenced flow, keep-alive | • | • | | • | 17 | | | Context | Multiplexing | • | • | • | • | 18 | | | UnsequencedHeartbeat | Keep-alive | | | • | | 19 | | | RetransmitRequest | Requests resynchronization | • | | | | 20 | | | Retransmission | Resynchronization | • | | | | 21 | | Unbinding | Terminate | Unbinds a transport | • | • | • | | 22 | | Finalizing | FinishedSending | Ends a logical flow | • | • | • | • | 23 | | | FinishedReceiving | Ends a logical flow | • | • | • | • | 24 | 25 | Related Application Messages 26 | ---------------------------- 27 | 28 | These optional application messages respond to application messages on an idempotent flow. 29 | 30 | | Stage | Message Name | Purpose | 31 | |--------------|--------------|---------------------------------------------------| 32 | | Transferring | Applied | Acknowledge idempotent operations | 33 | | | NotApplied | Negative acknowledgement of idempotent operations | 34 | 35 | Summary of Protocol Violations 36 | ------------------------------ 37 | 38 | If any of these violations by a peer is detected, the session should be terminated. 39 | 40 | - Sending a session message that is inappropriate to the flow type, such as a Sequence message on an unsequenced flow. See table above. 41 | 42 | - *Sending an application message on a session that is not in established state.* 43 | 44 | - *Reusing the session ID of a session that was finalized.* 45 | 46 | - Sending a RetransmitRequest while a retransmission is in progress. 47 | 48 | - *Sending a RetransmitRequest with request range out of bounds. That is, it is a violation to request a retransmission of a message with a sequence number that has not been sent yet.* 49 | -------------------------------------------------------------------------------- /v1-0-RC3/doc/08RulesOfEngagement.md: -------------------------------------------------------------------------------- 1 | Appendix B – FIXP Rules of Engagement 2 | ===================================== 3 | 4 | This checklist is an aid to specifying a full protocol stack to be used for communication between counterparties 5 | 6 | | Stack layer | Client | Server | 7 | |---------------------------------------|----------------------------|-------------| 8 | | **Application Layer** | | | 9 | | Application level recovery supported? | | | 10 | | FIX version | | | 11 | | Service pack | | | 12 | | Extension packs | | | 13 | | **Presentation Layer** | | | 14 | | Message encoding | | | 15 | | Version | | | 16 | | Schema/templates | | | 17 | | Framing | | | 18 | | **Session Layer** | | | 19 | | Supported flow types | | | 20 | | **Security protocols** | | | 21 | | Authentication | | | 22 | | **Transport Layer** | | | 23 | | Transports supported | | | 24 | | Other network protocols | | | -------------------------------------------------------------------------------- /v1-0-RC3/doc/media/FlowFinalization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC3/doc/media/FlowFinalization.png -------------------------------------------------------------------------------- /v1-0-RC3/doc/media/Idempotent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC3/doc/media/Idempotent.png -------------------------------------------------------------------------------- /v1-0-RC3/doc/media/Retransmission.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC3/doc/media/Retransmission.png -------------------------------------------------------------------------------- /v1-0-RC3/doc/media/RetransmissionReject.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC3/doc/media/RetransmissionReject.png -------------------------------------------------------------------------------- /v1-0-RC3/doc/media/RetransmitViolation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC3/doc/media/RetransmitViolation.png -------------------------------------------------------------------------------- /v1-0-RC3/doc/media/SessionEstablishment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC3/doc/media/SessionEstablishment.png -------------------------------------------------------------------------------- /v1-0-RC3/doc/media/SessionNegotiation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC3/doc/media/SessionNegotiation.png -------------------------------------------------------------------------------- /v1-0-RC3/doc/media/UnbindTransport-TCP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC3/doc/media/UnbindTransport-TCP.png -------------------------------------------------------------------------------- /v1-0-RC3/doc/media/UnbindTransport-UDP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC3/doc/media/UnbindTransport-UDP.png -------------------------------------------------------------------------------- /v1-0-RC3/doc/media/image1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC3/doc/media/image1.jpeg -------------------------------------------------------------------------------- /v1-0-RC3/resources/SBEschemaForFIXP.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 0 20 | 1 21 | 2 22 | 3 23 | 24 | 25 | 0 26 | 1 27 | 2 28 | 3 29 | 30 | 31 | 0 32 | 1 33 | 2 34 | 3 35 | 4 36 | 5 37 | 38 | 39 | 0 40 | 1 41 | 2 42 | 43 | 44 | 0 45 | 1 46 | 2 47 | 3 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | -------------------------------------------------------------------------------- /v1-0-RC4/doc/00Contents.md: -------------------------------------------------------------------------------- 1 | Contents 2 | ======== 3 | 4 | [Title](00Title.md) 5 | 6 | [1. Introduction](01Introduction.md) 7 | 8 | [2. Requirements](02Requirements.md) 9 | 10 | [3. Common Features](03CommonFeatures.md) 11 | 12 | [4. Point to Point Session Protocol](04PointToPointSessionProtocol.md) 13 | 14 | [5. Multicast Session Protocol](05MulticastSessionProtocol.md) 15 | 16 | [6. Summary of Session Messages](06SummaryOfSessionMessages.md) 17 | 18 | [7. Appendix A: Usage Examples](07UsageExamples.md) 19 | 20 | [8. Appendix B: Rules of Engagement](08RulesOfEngagement.md) -------------------------------------------------------------------------------- /v1-0-RC4/doc/00Title.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | # FIX Performance Session Layer 6 | 7 | ## Technical Specification 8 | 9 | ## Release Candidate 4 10 | 11 | May 2, 2018 12 | 13 | **THIS DOCUMENT IS A RELEASE CANDIDATE FOR A PROPOSED FIX TECHNICAL STANDARD. A RELEASE CANDIDATE HAS BEEN APPROVED BY THE GLOBAL TECHNICAL COMMITTEE AS AN INITIAL STEP IN CREATING A NEW FIX TECHNICAL STANDARD. POTENTIAL ADOPTERS ARE STRONGLY ENCOURAGED TO BEGIN WORKING WITH THE RELEASE CANDIDATE AND TO PROVIDE FEEDBACK TO THE GLOBAL TECHNICAL COMMITTEE AND THE WORKING GROUP THAT SUBMITTED THE PROPOSAL. THE FEEDBACK TO THE RELEASE CANDIDATE WILL DETERMINE IF ANOTHER REVISION AND RELEASE CANDIDATE IS NECESSARY OR IF THE RELEASE CANDIDATE CAN BE PROMOTED TO BECOME A FIX TECHNICAL STANDARD DRAFT.** 14 | 15 | 16 | 17 | DISCLAIMER 18 | 19 | THE INFORMATION CONTAINED HEREIN AND THE FINANCIAL INFORMATION EXCHANGE PROTOCOL (COLLECTIVELY, THE "FIX PROTOCOL") ARE PROVIDED "AS IS" AND NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL MAKES ANY REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED, AS TO THE FIX PROTOCOL (OR THE RESULTS TO BE OBTAINED BY THE USE THEREOF) OR ANY OTHER MATTER AND EACH SUCH PERSON AND ENTITY SPECIFICALLY DISCLAIMS ANY WARRANTY OF ORIGINALITY, ACCURACY, COMPLETENESS, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SUCH PERSONS AND ENTITIES DO NOT WARRANT THAT THE FIX PROTOCOL WILL CONFORM TO ANY DESCRIPTION THEREOF OR BE FREE OF ERRORS. THE ENTIRE RISK OF ANY USE OF THE FIX PROTOCOL IS ASSUMED BY THE USER. 20 | 21 | NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL SHALL HAVE ANY LIABILITY FOR DAMAGES OF ANY KIND ARISING IN ANY MANNER OUT OF OR IN CONNECTION WITH ANY USER'S USE OF (OR ANY INABILITY TO USE) THE FIX PROTOCOL, WHETHER DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL (INCLUDING, WITHOUT LIMITATION, LOSS OF DATA, LOSS OF USE, CLAIMS OF THIRD PARTIES OR LOST PROFITS OR REVENUES OR OTHER ECONOMIC LOSS), WHETHER IN TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), CONTRACT OR OTHERWISE, WHETHER OR NOT ANY SUCH PERSON OR ENTITY HAS BEEN ADVISED OF, OR OTHERWISE MIGHT HAVE ANTICIPATED THE POSSIBILITY OF, SUCH DAMAGES. 22 | 23 | **DRAFT OR NOT RATIFIED PROPOSALS** (REFER TO PROPOSAL STATUS AND/OR SUBMISSION STATUS ON COVER PAGE) ARE PROVIDED "AS IS" TO INTERESTED PARTIES FOR DISCUSSION ONLY. PARTIES THAT CHOOSE TO IMPLEMENT THIS DRAFT PROPOSAL DO SO AT THEIR OWN RISK. IT IS A DRAFT DOCUMENT AND MAY BE UPDATED, REPLACED, OR MADE OBSOLETE BY OTHER DOCUMENTS AT ANY TIME. THE FIX GLOBAL TECHNICAL COMMITTEE WILL NOT ALLOW EARLY IMPLEMENTATION TO CONSTRAIN ITS ABILITY TO MAKE CHANGES TO THIS SPECIFICATION PRIOR TO FINAL RELEASE. IT IS INAPPROPRIATE TO USE FIX WORKING DRAFTS AS REFERENCE MATERIAL OR TO CITE THEM AS OTHER THAN “WORKS IN PROGRESS”. THE FIX GLOBAL TECHNICAL COMMITTEE WILL ISSUE, UPON COMPLETION OF REVIEW AND RATIFICATION, AN OFFICIAL STATUS ("APPROVED") OF/FOR THE PROPOSAL AND A RELEASE NUMBER. 24 | 25 | No proprietary or ownership interest of any kind is granted with respect to the FIX Protocol (or any rights therein). 26 | 27 | Copyright 2013-2018 FIX Protocol Ltd., all rights reserved. 28 | 29 | 30 | FIX Performance Session Layer specification by [FIX Protocol Ltd.](http://www.fixtradingcommunity.org/) is licensed under a [Creative Commons Attribution-NoDerivatives 4.0 International License](http://creativecommons.org/licenses/by-nd/4.0/). 31 | Based on a work at . 32 | -------------------------------------------------------------------------------- /v1-0-RC4/doc/01Introduction.md: -------------------------------------------------------------------------------- 1 | Introduction 2 | ============ 3 | 4 | FIX Performance Session Layer (FIXP) is a “lightweight point-to-point protocol” introduced to provide an open industry standard for high performance computing requirements currently encountered by the FIX Community. FIXP is a derived work. The origin and basis for FIXP are the FIX session layer protocols and the designed and implemented by NASDAQOMX, SoupTCP, SoupBinTCP, and UFO (UDP for Orders). Every attempt was made to keep FIXP as close to the functionality and behavior of SoupBinTCP and UFO as possible. Extensions and refactoring were performed as incremental improvements. Every attempt was made to limit the FIXP to establishing and maintaining a communication session between two end points in a reliable manner, regardless of the reliability of the underlying transport. 5 | 6 | FIXP features 7 | 8 | - Binary protocol 9 | 10 | - Very simple lightweight point-to-point session layer for reliable communication. 11 | 12 | - Communication protocol independent 13 | 14 | - Encoding independent 15 | 16 | - Restricted to initiating, maintaining, and reestablishing a session. 17 | 18 | 19 | Authors 20 | ------- 21 | 22 | | Name | Affiliation | Contact | Role 23 | |-----------------|-------------------------|------------------------------|--------------------------------------------------------------------------------------| 24 | | Anders Furuhed | Goldman Sachs | | Protocol Designer 25 | | David Rosenborg | Goldman Sachs | | Protocol Designer 26 | | Rolf Andersson | Goldman Sachs | | Contributor 27 | | Jim Northey | LaSalle Technology | | Global Technical Committee co-chair 28 | | Júlio L R Monteiro | formerly B3 | | Editor, Working Group convener 29 | | Aditya Kapur | CME Group, Inc | | Contributor 30 | | Don Mendelson | Silver Flash LLC | | Working Group Lead | 31 | | Li Zhu | Shanghai Stock Exchange | | Contributor | 32 | 33 | 34 | ### Related FIX Standards 35 | 36 | The FIX Simple Open Framing Header standard governs how messages are delimited and has a specific relationship mentioned in this specification. FIXP interoperates with the other FIX standards at application and presentation layers, but it is not dependent on them. Therefore, they are considered non-normative for FIXP. 37 | 38 | | Related Standard | Version | Reference location | Relationship | Normative | 39 | |------------------------------|----------------|------------------------|--------------------------------------|---------------| 40 | | Simple Open Framing Header | Draft Standard | [SOFH](https://www.fixtrading.org/packages/fix-simple-open-framing-header-draft-standard-1-0/) | Optional usage at presentation layer | Yes | 41 | | FIX message specifications | 5.0 SP2 | [FIX 5.0 SP2](https://www.fixtrading.org/packages/fix-5-0-service-pack-2-specification-w-20110818-errata/) | Presentation and application layers | No | 42 | | FIX Simple Binary Encoding | Version 1.0 | [Simple Binary Encoding](https://www.fixtrading.org/packages/simple-binary-encoding-technical-specification-final/) | Optional usage at presentation layer | No | 43 | | Encoding FIX Using ASN.1 | Draft Standard | [ASN.1](https://www.fixtrading.org/packages/encoding-fix-using-asn-1-draft-standard/) | Optional usage at presentation layer | No | 44 | | Encoding FIX Using GPB | RC2 | [GPB](https://www.fixtrading.org/packages/encoding-fix-using-google-protocol-buffers-release-candidate-2/) | Optional usage at presentation layer | No | 45 | 46 | ### Dependencies on Other Specifications 47 | 48 | FIXP is dependent on several industry standards. Implementations of FIXP must conform to these standards to interoperate. Therefore, they are normative for FIXP. Other protocols may be used by agreement between counterparties. 49 | 50 | 51 | | Related Standard | Version | Reference location | Relationship | Normative | 52 | |--------------------------------------------------------------|-------------|--------------------------------------|---------------------------------|---------------| 53 | | RFC 793 Transmission Control Program (TCP) | N/A | and related standards | Uses transport | Yes | 54 | | RFC 768 User Datagram Protocol (UDP) | N/A | | Uses transport | Yes | 55 | | RFC4122 A Universally Unique Identifier (UUID) URN Namespace | N/A | | Uses | Yes | 56 | | UTF-8, a transformation format of ISO 10646 | N/A | | Uses encoding | Yes | 57 | | Various authentication protocols | N/A | | Optional usage at session layer | No | 58 | 59 | ## Specification terms 60 | 61 | These key words in this document are to be interpreted as described in 62 | [Internet Engineering Task Force RFC2119](http://www.apps.ietf.org/rfc/rfc2119.html). These terms indicate 63 | an absolute requirement for implementations of the standard: "**must**", 64 | or "**required**". 65 | 66 | This term indicates an absolute prohibition: "**must not**". 67 | 68 | These terms indicate that a feature is allowed by the standard but not 69 | required: "**may**", "**optional**". An implementation that does not 70 | provide an optional feature must be prepared to interoperate with one 71 | that does. 72 | 73 | These terms give guidance, recommendation or best practices: 74 | "**should**" or "**recommended**". A recommended choice among 75 | alternatives is described as "**preferred**". 76 | 77 | These terms give guidance that a practice is not recommended: "**should not**" 78 | or "**not recommended**". 79 | 80 | Definitions 81 | ----------- 82 | 83 | | Term | Definition | 84 | |---------|-------------| 85 | | Client | Initiator of session 86 | | Credentials | User identification for authentication 87 | | Flow | A unidirectional stream of messages. Each flow has one producer and one or more consumers. 88 | | Idempotence | Idempotence means that an operation that is applied multiple times does not change the outcome, the result, after the first time 89 | | Multicast | A method of sending datagrams from one producer to multiple consumers 90 | | IETF | Internet Engineering Task Force 91 | | Server | Acceptor of session 92 | | Session | A dialog for exchanging application messages between peers. An established point-to-point session consists of a pair of flows, one in each direction between peers. A multicast session consists of a single flow from the producer to multiple consumers. 93 | | TCP | Transmission Control Protocol is a set of IETF standards for a reliable stream of data exchanged between peers. Since it is connection oriented, it incorporates some features of a session protocol. 94 | | TLS | Transport Layer Security is a set of IETF standards to provide security to a session. TLS is a successor to Secure Sockets Layer (SSL). 95 | | UDP | User Datagram Protocol is a connectionless transmission for delivering packets of data. Any rules for a long-lived exchange of messages must be supplied by a session protocol. -------------------------------------------------------------------------------- /v1-0-RC4/doc/02Requirements.md: -------------------------------------------------------------------------------- 1 | Requirements 2 | ============ 3 | 4 | Business Requirements 5 | --------------------- 6 | 7 | Create an enhanced session protocol that can provide reliable, highly efficient, exchange of messages to support high performance financial messaging, over a variety of transports. 8 | 9 | Protocol shall be fit for purpose for current high message rates, low latency environments in financial markets, but should be to every extent possible applicable to other business domains. There is no reason to limit or couple the session layer to the financial markets / trading business domain without extraordinary reason. 10 | 11 | Support common message flow types: Recoverable, Unsequenced, Idempotent (operations guaranteed to be applied only once), and None (for a one-way flow of messages). 12 | 13 | Protocol shall support asymmetric models, such as market participant to market, in addition to peer-to-peer (symmetric). Allow the communication of messages to multiple receivers (broadcast). 14 | 15 | The session protocol does not require or recommend a specific authentication protocol. Counterparties are free to agree on user authentication techniques that fit their needs. 16 | 17 | Technical Requirements 18 | ---------------------- 19 | 20 | ### Protocol Layering 21 | 22 | This standard endeavors to maintain a clear separation of protocol layers, as expressed by the Open Systems Interconnection model (OSI). The responsibilities of a session layer are establishment, termination and restart procedures and rules for the exchange of application messages. 23 | 24 | The protocol shall be independent of message encoding (presentation layer), to provide the maximum utility. Encoding independence applies both to session layer messages specified in this document as well as to application messages. It is simpler if session protocol messages are encoded the same way as application messages, but that is not a requirement of this session protocol. 25 | 26 | Users are free to specify message encodings by agreement with counterparties. FIX provides Simple Binary Encoding as well as mappings of FIX to other high performance encodings such as ASN.1, and Google Protocol Buffers. See the list of related standards above. Other recognized encodings may follow in the future. 27 | 28 | Of necessity, the session protocol makes some adaptations for transport layer protocols used by the session layer since the capabilities of common transports are quite different. In particular, TCP is connection- and stream-oriented and implements its own reliable delivery mechanisms. Meanwhile, UDP is datagram-oriented and does not guarantee delivery in order. Unfortunately, these characteristics bleed across protocol layers. 29 | 30 | ### Security Mechanisms 31 | 32 | FIXP does not specify its own security features. Rather, the FIX Trading Community separately issues security requirements and recommendations that may apply to FIXP 33 | and other FIX session protocols. Due to the ever-changing nature of information security, the requirements and recommendations are likely to be updated periodically. In general, it is recommended that FIX traffic be protected by using proven controls specified by the FIX Trading Community. 34 | 35 | The FIX Trading Community is in the process of specifying how to authenticate parties using TLS and optionally using FIX credentials. FIX credentials can be used to authenticate a client after an underlying TLS session has been established. FIXP supports this use case by providing a field for credentials in the FIXP session negotiation handshake. 36 | 37 | ### Low Overhead 38 | 39 | Minimum overhead is added to the messages exchanged between peers, using only the strictly necessary control messages. 40 | 41 | By agreement between counterparties, a message framing protocol may be used to delimit messages. This relieves the session layer of application message decoding to determine message boundaries. FIX offers the Simple Open Framing Header standard for framing messages encoded with binary wire formats. See standards references above. 42 | -------------------------------------------------------------------------------- /v1-0-RC4/doc/05MulticastSessionProtocol.md: -------------------------------------------------------------------------------- 1 | Multicast Session Protocol 2 | ========================== 3 | 4 | A multicast session conveys messages one way from a publisher to any number of listeners. It is conducted over a connectionless transport such UDP multicast. Multicast session protocol is typically used for publishing market data or common reference information to many consumers. Multiple independent flows may be multiplexed over a shared multicast transport. 5 | 6 | Multicast Session Lifecycle 7 | --------------------------- 8 | 9 | Since a multicast transport is connectionless, there is no negotiation or binding or unbinding of the transport as in the point-to-point protocol. Thus, Negotiation and Establishment messages and their respective responses are not used. 10 | 11 | Multicast addresses and publishing schedules must be provided out-of-band to listeners. To capture all messages, listeners must be ready to receive at scheduled times. Publishing continues until the end of a logical flow. 12 | 13 | ### Multicast Session Establishment 14 | 15 | Like a point-to-point session, a multicast session is identified by a UUID. Each time a session is initiated, a new UUID must be generated, and sequence numbers of subsequent application messages must begin with 1. 16 | 17 | #### Topic Message 18 | 19 | To associate a transient UUID to a permanent or semi-permanent classification of messages, a Topic message must be used to initiate a flow. Multiple topics may be published on a transport. 20 | 21 | FlowType = Recoverable | Idempotent 22 | 23 | Valid flow types on a multicast session are: 24 | 25 | - **Recoverable**: Messages are sequenced and recoverable. Since the transport is one-way, RetransmitRequests must be delivered through a separate session, however. 26 | 27 | - **Idempotent**: Messages are sequenced to allow detection of loss but any missed messages are not recoverable. 28 | 29 | Each Topic carries a Classification for the flow to associate it to a permanent or semi-permanent application layer entity. Typical classifications are product types, market symbols or the like. 30 | 31 | To support late joiners, Topic messages should be repeated at regular intervals on a session. This specification does not dictate a specific interval, but the shorter the interval, the less time it takes for a late joiner to identify flows. It is recommended that Topic message be sent with Session heartbeats when the session is otherwise idle. See session heartbeat section below. 32 | 33 | **Topic** 34 | 35 | | **Field name** | **Type** | **Required** | **Value** | **Description** | 36 | |----------------|----------|--------------|-----------|-----------------| 37 | | MessageType | Enum | Y | Topic | | 38 | | SessionId | UUID | Y | | Session Identifier 39 | | Flow | FlowType Enum | Y | | Type of flow from publisher 40 | | Classification | Object | Y | | Category of application messages that follow 41 | 42 | ### Finalizing a Multicast Session 43 | 44 | Finalization ends a logical flow when there are no more application messages to send. A multicast flow should be finalized by transmitting a FinishedSending message. No further messages should be sent, and the session ID is no longer valid after that. 45 | 46 | Idempotent Flow over Multicast 47 | ------------------------------ 48 | The goal of an idempotent flow over multicast is to provide at-most-once delivery guarantee to each consumer. Unlike a point-to-point session, however, there is no opportunity to return a NotApplied message to the producer over a one-way transport if a sequence number gap is detected. Therefore, on a multicast, an idempotent flow provides a means to detect data loss, but no direct way to notify the producer or initiate recovery. 49 | 50 | An idempotent flow is implemented by the producer in the same way over a multicast transport as for point-to-point over UDP unicast. Each datagram must begin with either a Sequence message if non-multiplexed or a Context message if the flow is sent over a multiplexed transport. 51 | 52 | Session Heartbeat 53 | ----------------- 54 | 55 | During the lifetime of a multicast session, its publisher should send Sequence or Context messages as a heartbeat at regular intervals when the session is otherwise inactive. This allows a receiver to tell whether a session is live and has not reached the end of its logical flow. If only a single Topic is published, then Sequence message may be used for heartbeats since there is no context switch. If multiple topics are published on a shared multicast transport, then Context must be used. See the Common Features section above for a description of sequence numbering and the Sequence and Context messages. 56 | 57 | In addition to the Sequence or Context message, it is recommended that a Topic message should be published on the heartbeat interval. This provides an opportunity for late joiners to gather session characteristics during every idle period. -------------------------------------------------------------------------------- /v1-0-RC4/doc/06SummaryOfSessionMessages.md: -------------------------------------------------------------------------------- 1 | Summary of Session Messages 2 | =========================== 3 | 4 | FIXP Session Messages 5 | --------------------- 6 | 7 | | Stage | Message Name | Purpose | Recoverable | Idempotent | Unsequenced / None | Multicast | 8 | |----------------|----------------------|----------------------------------------|:-------------:|:------------:|:------------------:|:---------:| 9 | | Initialization | Negotiate | Initiates session | • | • | • | | 10 | | | NegotiationResponse | Accepts session | • | • | • | | 11 | | | NegotiationReject | Rejects session | • | • | • | | 12 | | | Topic | Announces a flow | | | | • | 13 | | | MessageTemplate | Delivers template | • | • | • | • | 14 | | Binding | Establish | Binds session to transport | • | • | • | | 15 | | | EstablishmentAck | Accepts binding | • | • | • | | 16 | | | EstablishmentReject | Rejects binding | • | • | • | | 17 | | Transferring | Sequence | Initiates a sequenced flow, keep-alive | • | • | | • | 18 | | | Context | Multiplexing | • | • | • | • | 19 | | | UnsequencedHeartbeat | Keep-alive | | | • | | 20 | | | RetransmitRequest | Requests resynchronization | • | | | | 21 | | | Retransmission | Resynchronization | • | | | | 22 | | Unbinding | Terminate | Unbinds a transport | • | • | • | | 23 | | Finalizing | FinishedSending | Ends a logical flow | • | • | • | • | 24 | | | FinishedReceiving | Ends a logical flow | • | • | • | • | 25 | 26 | Related Application Messages 27 | ---------------------------- 28 | 29 | These optional application messages respond to application messages on an idempotent flow. 30 | 31 | | Stage | Message Name | Purpose | 32 | |--------------|--------------|---------------------------------------------------| 33 | | Transferring | Applied | Acknowledge idempotent operations | 34 | | | NotApplied | Negative acknowledgement of idempotent operations | 35 | 36 | Summary of Protocol Violations 37 | ------------------------------ 38 | 39 | If any of these violations by a peer is detected, the session should be immediately terminated. Any application messages that cause a violation, such as a message sent after FinishedSending, should be ignored. 40 | 41 | - Sending a session message that is inappropriate to the flow type, such as a Sequence message on an unsequenced flow. See table above. 42 | - Sending an application message on a point-to-point session that is not in established state. That is, prior to EstablishmentAck. 43 | - Sending Establish without having successfully negotiated a session. That is, a NegotiationResponse must have been received for the session. 44 | - Sending an application message after logical flow has been finalized with FinishedSending. The responder on a point-to-point session may not send an application message after sending FinishedReceiving. 45 | - Sending FinishedReceiving without having received FinishedSending from the peer. 46 | - Sending any application or session message after sending Terminate. 47 | - Reusing the session ID of a session that was finalized. (The server may have a practical limit of session history to enforce this rule.) 48 | - Sending a RetransmitRequest while a retransmission is in progress. 49 | - Sending a RetransmitRequest with request range out of bounds. That is, it is a violation to request a retransmission of a message with a sequence number that has not been sent yet. 50 | 51 | -------------------------------------------------------------------------------- /v1-0-RC4/doc/08RulesOfEngagement.md: -------------------------------------------------------------------------------- 1 | Appendix B – FIXP Rules of Engagement 2 | ===================================== 3 | 4 | This checklist is an aid to specifying a full protocol stack to be used for communication between counterparties 5 | 6 | | Stack layer | Client | Server | 7 | |---------------------------------------|----------------------------|-------------| 8 | | **Application Layer** | | | 9 | | Application level recovery supported? | | | 10 | | FIX version | | | 11 | | Service pack | | | 12 | | Extension packs | | | 13 | | **Presentation Layer** | | | 14 | | Message encoding | | | 15 | | Version | | | 16 | | Schema/templates | | | 17 | | Framing | | | 18 | | **Session Layer** | | | 19 | | Supported flow types | | | 20 | | **Security protocols** | | | 21 | | TLS version | | 22 | | Authentication | | | 23 | | Cipher suites | | | 24 | | **Transport Layer** | | | 25 | | Transports supported | | | 26 | | Other network protocols | | | -------------------------------------------------------------------------------- /v1-0-RC4/doc/media/FlowFinalization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC4/doc/media/FlowFinalization.png -------------------------------------------------------------------------------- /v1-0-RC4/doc/media/Idempotent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC4/doc/media/Idempotent.png -------------------------------------------------------------------------------- /v1-0-RC4/doc/media/Retransmission.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC4/doc/media/Retransmission.png -------------------------------------------------------------------------------- /v1-0-RC4/doc/media/RetransmissionReject.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC4/doc/media/RetransmissionReject.png -------------------------------------------------------------------------------- /v1-0-RC4/doc/media/RetransmitViolation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC4/doc/media/RetransmitViolation.png -------------------------------------------------------------------------------- /v1-0-RC4/doc/media/SessionEstablishment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC4/doc/media/SessionEstablishment.png -------------------------------------------------------------------------------- /v1-0-RC4/doc/media/SessionNegotiation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC4/doc/media/SessionNegotiation.png -------------------------------------------------------------------------------- /v1-0-RC4/doc/media/UnbindTransport-TCP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC4/doc/media/UnbindTransport-TCP.png -------------------------------------------------------------------------------- /v1-0-RC4/doc/media/UnbindTransport-UDP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC4/doc/media/UnbindTransport-UDP.png -------------------------------------------------------------------------------- /v1-0-RC4/doc/media/image1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-RC4/doc/media/image1.jpeg -------------------------------------------------------------------------------- /v1-0-RC4/resources/SBEschemaForFIXP.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 0 19 | 1 20 | 2 21 | 3 22 | 23 | 24 | 0 25 | 1 26 | 2 27 | 3 28 | 29 | 30 | 0 31 | 1 32 | 2 33 | 3 34 | 4 35 | 5 36 | 37 | 38 | 0 39 | 1 40 | 2 41 | 42 | 43 | 0 44 | 1 45 | 2 46 | 3 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/01Introduction.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | FIX Performance Session Layer (FIXP) is a “lightweight point-to-point protocol” introduced to provide an open industry standard for high performance computing requirements currently encountered by the FIX Community. FIXP is a derived work. The origin and basis for FIXP are the FIX session layer protocols and the designed and implemented by NASDAQOMX, SoupTCP, SoupBinTCP, and UFO (UDP for Orders). Every attempt was made to keep FIXP as close to the functionality and behavior of SoupBinTCP and UFO as possible. Extensions and refactoring were performed as incremental improvements. Every attempt was made to limit the FIXP to establishing and maintaining a communication session between two end points in a reliable manner, regardless of the reliability of the underlying transport. 4 | 5 | FIXP features 6 | 7 | - Binary protocol 8 | 9 | - Very simple lightweight point-to-point session layer for reliable communication. 10 | 11 | - Communication protocol independent 12 | 13 | - Encoding independent 14 | 15 | - Restricted to initiating, maintaining, and reestablishing a session. 16 | 17 | 18 | ## Authors 19 | 20 | | Name | Affiliation | Contact | Role 21 | |-----------------|-------------------------|------------------------------|--------------------------------------------------------------------------------------| 22 | | Anders Furuhed | Goldman Sachs | | Protocol Designer 23 | | David Rosenborg | Goldman Sachs | | Protocol Designer 24 | | Rolf Andersson | Goldman Sachs | | Contributor 25 | | Jim Northey | LaSalle Technology | | Global Technical Committee co-chair 26 | | Júlio L R Monteiro | formerly B3 | | Editor, Working Group convener 27 | | Aditya Kapur | CME Group, Inc | | Contributor 28 | | Don Mendelson | Silver Flash LLC | | Working Group Lead | 29 | | Li Zhu | Shanghai Stock Exchange | | Contributor | 30 | 31 | 32 | ### Related FIX Standards 33 | 34 | The FIX Simple Open Framing Header standard governs how messages are delimited and has a specific relationship mentioned in this specification. FIXP interoperates with the other FIX standards at application and presentation layers, but it is not dependent on them. Therefore, they are considered non-normative for FIXP. 35 | 36 | | Related Standard | Version | Reference location | Relationship | Normative | 37 | |------------------------------|----------------|------------------------|--------------------------------------|---------------| 38 | | Simple Open Framing Header | Draft Standard | [SOFH](https://www.fixtrading.org/packages/fix-simple-open-framing-header-draft-standard-1-0/) | Optional usage at presentation layer | Yes | 39 | | FIX message specifications | 5.0 SP2 | [FIX 5.0 SP2](https://www.fixtrading.org/packages/fix-5-0-service-pack-2-specification-w-20110818-errata/) | Presentation and application layers | No | 40 | | FIX Simple Binary Encoding | Version 1.0 | [Simple Binary Encoding](https://www.fixtrading.org/packages/simple-binary-encoding-technical-specification-final/) | Optional usage at presentation layer | No | 41 | | Encoding FIX Using ASN.1 | Draft Standard | [ASN.1](https://www.fixtrading.org/packages/encoding-fix-using-asn-1-draft-standard/) | Optional usage at presentation layer | No | 42 | | Encoding FIX Using GPB | RC2 | [GPB](https://www.fixtrading.org/packages/encoding-fix-using-google-protocol-buffers-release-candidate-2/) | Optional usage at presentation layer | No | 43 | 44 | ### Dependencies on Other Specifications 45 | 46 | FIXP is dependent on several industry standards. Implementations of FIXP must conform to these standards to interoperate. Therefore, they are normative for FIXP. Other protocols may be used by agreement between counterparties. 47 | 48 | 49 | | Related Standard | Version | Reference location | Relationship | Normative | 50 | |--------------------------------------------------------------|-------------|--------------------------------------|---------------------------------|---------------| 51 | | RFC 793 Transmission Control Protocol (TCP) | N/A | and related standards | Uses transport | Yes | 52 | | RFC 768 User Datagram Protocol (UDP) | N/A | | Uses transport | Yes | 53 | | RFC4122 A Universally Unique Identifier (UUID) URN Namespace | N/A | | Uses | Yes | 54 | | UTF-8, a transformation format of ISO 10646 | N/A | | Uses encoding | Yes | 55 | | Various authentication protocols | N/A | | Optional usage at session layer | No | 56 | 57 | ## Specification terms 58 | 59 | These key words in this document are to be interpreted as described in 60 | [Internet Engineering Task Force RFC2119](http://www.apps.ietf.org/rfc/rfc2119.html). These terms indicate 61 | an absolute requirement for implementations of the standard: "**must**", 62 | or "**required**". 63 | 64 | This term indicates an absolute prohibition: "**must not**". 65 | 66 | These terms indicate that a feature is allowed by the standard but not 67 | required: "**may**", "**optional**". An implementation that does not 68 | provide an optional feature must be prepared to interoperate with one 69 | that does. 70 | 71 | These terms give guidance, recommendation or best practices: 72 | "**should**" or "**recommended**". A recommended choice among 73 | alternatives is described as "**preferred**". 74 | 75 | These terms give guidance that a practice is not recommended: "**should not**" 76 | or "**not recommended**". 77 | 78 | ## Definitions 79 | 80 | | Term | Definition | 81 | |-------------|-------------| 82 | | Client | Initiator of session 83 | | Credentials | User identification for authentication 84 | | Flow | A unidirectional stream of messages. Each flow has one producer and one or more consumers. 85 | | Idempotence | Idempotence means that an operation that is applied multiple times does not change the outcome, the result, after the first time 86 | | Multicast | A method of sending datagrams from one producer to multiple consumers 87 | | IETF | Internet Engineering Task Force 88 | | Server | Acceptor of session 89 | | Session | A dialog for exchanging application messages between peers. An established point-to-point session consists of a pair of flows, one in each direction between peers. A multicast session consists of a single flow from the producer to multiple consumers. 90 | | TCP | Transmission Control Protocol is a set of IETF standards for a reliable stream of data exchanged between peers. Since it is connection oriented, it incorporates some features of a session protocol. 91 | | TLS | Transport Layer Security is a set of IETF standards to provide security to a session. TLS is a successor to Secure Sockets Layer (SSL). 92 | | UDP | User Datagram Protocol is a connectionless transmission for delivering packets of data. Any rules for a long-lived exchange of messages must be supplied by a session protocol. 93 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/02Requirements.md: -------------------------------------------------------------------------------- 1 | # Requirements 2 | 3 | ## Business Requirements 4 | 5 | Create an enhanced session protocol that can provide reliable, highly efficient, exchange of messages to support high performance financial messaging, over a variety of transports. 6 | 7 | Protocol shall be fit for purpose for current high message rates, low latency environments in financial markets, but should be to every extent possible applicable to other business domains. There is no reason to limit or couple the session layer to the financial markets / trading business domain without extraordinary reason. 8 | 9 | Support common message flow types: Recoverable, Unsequenced, Idempotent (operations guaranteed to be applied only once), and None (for a one-way flow of messages). 10 | 11 | Protocol shall support asymmetric models, such as market participant to market, in addition to peer-to-peer (symmetric). Allow the communication of messages to multiple receivers (broadcast). 12 | 13 | The session protocol does not require or recommend a specific authentication protocol. Counterparties are free to agree on user authentication techniques that fit their needs. 14 | 15 | ## Technical Requirements 16 | 17 | ### Protocol Layering 18 | 19 | This standard endeavors to maintain a clear separation of protocol layers, as expressed by the Open Systems Interconnection model (OSI). The responsibilities of a session layer are establishment, termination and restart procedures and rules for the exchange of application messages. 20 | 21 | The protocol shall be independent of message encoding (presentation layer), to provide the maximum utility. Encoding independence applies both to session layer messages specified in this document as well as to application messages. It is simpler if session protocol messages are encoded the same way as application messages, but that is not a requirement of this session protocol. 22 | 23 | Users are free to specify message encodings by agreement with counterparties. FIX provides Simple Binary Encoding as well as mappings of FIX to other high performance encodings such as ASN.1, and Google Protocol Buffers. See the list of related standards above. Other recognized encodings may follow in the future. 24 | 25 | Of necessity, the session protocol makes some adaptations for transport layer protocols used by the session layer since the capabilities of common transports are quite different. In particular, TCP is connection- and stream-oriented and implements its own reliable delivery mechanisms. Meanwhile, UDP is datagram-oriented and does not guarantee delivery in order. Unfortunately, these characteristics bleed across protocol layers. 26 | 27 | ### Security Mechanisms 28 | 29 | FIXP does not specify its own security features. Rather, the FIX Trading Community separately issues security requirements and recommendations that may apply to FIXP 30 | and other FIX session protocols. Due to the ever-changing nature of information security, the requirements and recommendations are likely to be updated periodically. In general, it is recommended that FIX traffic be protected by using proven controls specified by the FIX Trading Community. 31 | 32 | The FIX Trading Community is in the process of specifying how to authenticate parties using TLS and optionally using FIX credentials. FIX credentials can be used to authenticate a client after an underlying TLS session has been established. FIXP supports this use case by providing a field for credentials in the FIXP session negotiation handshake. 33 | 34 | ### Low Overhead 35 | 36 | Minimum overhead is added to the messages exchanged between peers, using only the strictly necessary control messages. 37 | 38 | By agreement between counterparties, a message framing protocol may be used to delimit messages. This relieves the session layer of application message decoding to determine message boundaries. FIX offers the Simple Open Framing Header standard for framing messages encoded with binary wire formats. See standards references above. 39 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/05MulticastSessionProtocol.md: -------------------------------------------------------------------------------- 1 | # Multicast Session Protocol 2 | 3 | A multicast session conveys messages one way from a publisher to any number of listeners. It is conducted over a connectionless transport such UDP multicast. Multicast session protocol is typically used for publishing market data or common reference information to many consumers. Multiple independent flows may be multiplexed over a shared multicast transport. 4 | 5 | ## Multicast Session Lifecycle 6 | 7 | Since a multicast transport is connectionless, there is no negotiation or binding or unbinding of the transport as in the point-to-point protocol. Thus, Negotiation and Establishment messages and their respective responses are not used. 8 | 9 | Multicast addresses and publishing schedules must be provided out-of-band to listeners. To capture all messages, listeners must be ready to receive at scheduled times. Publishing continues until the end of a logical flow. 10 | 11 | ### Multicast Session Establishment 12 | 13 | Like a point-to-point session, a multicast session is identified by a UUID. Each time a session is initiated, a new UUID must be generated, and sequence numbers of subsequent application messages must begin with 1. 14 | 15 | #### Topic Message 16 | 17 | To associate a transient UUID to a permanent or semi-permanent classification of messages, a Topic message must be used to initiate a flow. Multiple topics may be published on a transport. 18 | 19 | FlowType = Recoverable | Idempotent 20 | 21 | Valid flow types on a multicast session are: 22 | 23 | - **Recoverable**: Messages are sequenced and recoverable. Since the transport is one-way, RetransmitRequests must be delivered through a separate session, however. 24 | 25 | - **Idempotent**: Messages are sequenced to allow detection of loss but any missed messages are not recoverable. 26 | 27 | Each Topic carries a Classification for the flow to associate it to a permanent or semi-permanent application layer entity. Typical classifications are product types, market symbols or the like. 28 | 29 | To support late joiners, Topic messages should be repeated at regular intervals on a session. This specification does not dictate a specific interval, but the shorter the interval, the less time it takes for a late joiner to identify flows. It is recommended that Topic message be sent with Session heartbeats when the session is otherwise idle. See session heartbeat section below. 30 | 31 | **Topic** 32 | 33 | | **Field name** | **Type** | **Required** | **Value** | **Description** | 34 | |----------------|----------|--------------|-----------|-----------------| 35 | | MessageType | Enum | Y | Topic | | 36 | | SessionId | UUID | Y | | Session Identifier 37 | | Flow | FlowType Enum | Y | | Type of flow from publisher 38 | | Classification | Object | Y | | Category of application messages that follow 39 | 40 | ### Finalizing a Multicast Session 41 | 42 | Finalization ends a logical flow when there are no more application messages to send. A multicast flow should be finalized by transmitting a FinishedSending message. No further messages should be sent, and the session ID is no longer valid after that. 43 | 44 | ## Idempotent Flow over Multicast 45 | The goal of an idempotent flow over multicast is to provide at-most-once delivery guarantee to each consumer. Unlike a point-to-point session, however, there is no opportunity to return a NotApplied message to the producer over a one-way transport if a sequence number gap is detected. Therefore, on a multicast, an idempotent flow provides a means to detect data loss, but no direct way to notify the producer or initiate recovery. 46 | 47 | An idempotent flow is implemented by the producer in the same way over a multicast transport as for point-to-point over UDP unicast. Each datagram must begin with either a Sequence message if non-multiplexed or a Context message if the flow is sent over a multiplexed transport. 48 | 49 | ## Session Heartbeat 50 | 51 | During the lifetime of a multicast session, its publisher should send Sequence or Context messages as a heartbeat at regular intervals when the session is otherwise inactive. This allows a receiver to tell whether a session is live and has not reached the end of its logical flow. If only a single Topic is published, then Sequence message may be used for heartbeats since there is no context switch. If multiple topics are published on a shared multicast transport, then Context must be used. See the Common Features section above for a description of sequence numbering and the Sequence and Context messages. 52 | 53 | In addition to the Sequence or Context message, it is recommended that a Topic message should be published on the heartbeat interval. This provides an opportunity for late joiners to gather session characteristics during every idle period. 54 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/06SummaryOfSessionMessages.md: -------------------------------------------------------------------------------- 1 | # Summary of Session Messages 2 | 3 | ## FIXP Session Messages 4 | 5 | | Stage | Message Name | Purpose | Recoverable | Idempotent | Unsequenced / None | Multicast | 6 | |----------------|----------------------|----------------------------------------|:-------------:|:------------:|:------------------:|:---------:| 7 | | Initialization | Negotiate | Initiates session | • | • | • | | 8 | | | NegotiationResponse | Accepts session | • | • | • | | 9 | | | NegotiationReject | Rejects session | • | • | • | | 10 | | | Topic | Announces a flow | | | | • | 11 | | | MessageTemplate | Delivers template | • | • | • | • | 12 | | Binding | Establish | Binds session to transport | • | • | • | | 13 | | | EstablishmentAck | Accepts binding | • | • | • | | 14 | | | EstablishmentReject | Rejects binding | • | • | • | | 15 | | Transferring | Sequence | Initiates a sequenced flow, keep-alive | • | • | | • | 16 | | | Context | Multiplexing | • | • | • | • | 17 | | | UnsequencedHeartbeat | Keep-alive | | | • | | 18 | | | RetransmitRequest | Requests resynchronization | • | | | | 19 | | | Retransmission | Resynchronization | • | | | | 20 | | Unbinding | Terminate | Unbinds a transport | • | • | • | | 21 | | Finalizing | FinishedSending | Ends a logical flow | • | • | • | • | 22 | | | FinishedReceiving | Ends a logical flow | • | • | • | • | 23 | 24 | ## Related Application Messages 25 | 26 | These optional application messages respond to application messages on an idempotent flow. 27 | 28 | | Stage | Message Name | Purpose | 29 | |--------------|--------------|---------------------------------------------------| 30 | | Transferring | Applied | Acknowledge idempotent operations | 31 | | | NotApplied | Negative acknowledgement of idempotent operations | 32 | 33 | Summary of Protocol Violations 34 | ------------------------------ 35 | 36 | If any of these violations by a peer is detected, the session should be immediately terminated. Any application messages that cause a violation, such as a message sent after FinishedSending, should be ignored. 37 | 38 | - Sending a session message that is inappropriate to the flow type, such as a Sequence message on an unsequenced flow. See table above. 39 | - Sending an application message on a point-to-point session that is not in established state. That is, prior to EstablishmentAck. 40 | - Sending Establish without having successfully negotiated a session. That is, a NegotiationResponse must have been received for the session. 41 | - Sending an application message after logical flow has been finalized with FinishedSending. The responder on a point-to-point session may not send an application message after sending FinishedReceiving. 42 | - Sending FinishedReceiving without having received FinishedSending from the peer. 43 | - Sending any application or session message after sending Terminate. 44 | - Reusing the session ID of a session that was finalized. (The server may have a practical limit of session history to enforce this rule.) 45 | - Sending a RetransmitRequest while a retransmission is in progress. 46 | - Sending a RetransmitRequest with request range out of bounds. That is, it is a violation to request a retransmission of a message with a sequence number that has not been sent yet. 47 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/08RulesOfEngagement.md: -------------------------------------------------------------------------------- 1 | # Appendix B -- FIXP Rules of Engagement 2 | 3 | This checklist is an aid to specifying a full protocol stack to be used for communication between counterparties. 4 | 5 | | Stack layer | Client | Server | 6 | |---------------------------------------|----------------------------|-------------| 7 | | **Application Layer** | | | 8 | | Application level recovery supported? | | | 9 | | FIX version | | | 10 | | Service pack | | | 11 | | Extension packs | | | 12 | | **Presentation Layer** | | | 13 | | Message encoding | | | 14 | | Version | | | 15 | | Schema/templates | | | 16 | | Framing | | | 17 | | **Session Layer** | | | 18 | | Supported flow types | | | 19 | | **Security protocols** | | | 20 | | TLS version | | 21 | | Authentication | | | 22 | | Cipher suites | | | 23 | | **Transport Layer** | | | 24 | | Transports supported | | | 25 | | Other network protocols | | | 26 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/FIXDisclaimerTechStd.md: -------------------------------------------------------------------------------- 1 | ::: {custom-style=Disclaimer} 2 | DISCLAIMER 3 | ::: 4 | 5 | THE INFORMATION CONTAINED HEREIN AND THE FINANCIAL INFORMATION EXCHANGE PROTOCOL (COLLECTIVELY, THE "FIX PROTOCOL") ARE PROVIDED "AS IS" AND NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL MAKES ANY REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED, AS TO THE FIX PROTOCOL (OR THE RESULTS TO BE OBTAINED BY THE USE THEREOF) OR ANY OTHER MATTER AND EACH SUCH PERSON AND ENTITY SPECIFICALLY DISCLAIMS ANY WARRANTY OF ORIGINALITY, ACCURACY, COMPLETENESS, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SUCH PERSONS AND ENTITIES DO NOT WARRANT THAT THE FIX PROTOCOL WILL CONFORM TO ANY DESCRIPTION THEREOF OR BE FREE OF ERRORS. THE ENTIRE RISK OF ANY USE OF THE FIX PROTOCOL IS ASSUMED BY THE USER. 6 | 7 | NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL SHALL HAVE ANY LIABILITY FOR DAMAGES OF ANY KIND ARISING IN ANY MANNER OUT OF OR IN CONNECTION WITH ANY USER'S USE OF (OR ANY INABILITY TO USE) THE FIX PROTOCOL, WHETHER DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL (INCLUDING, WITHOUT LIMITATION, LOSS OF DATA, LOSS OF USE, CLAIMS OF THIRD PARTIES OR LOST PROFITS OR REVENUES OR OTHER ECONOMIC LOSS), WHETHER IN TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), CONTRACT OR OTHERWISE, WHETHER OR NOT ANY SUCH PERSON OR ENTITY HAS BEEN ADVISED OF, OR OTHERWISE MIGHT HAVE ANTICIPATED THE POSSIBILITY OF, SUCH DAMAGES. 8 | 9 | **DRAFT OR NOT RATIFIED PROPOSALS** (REFER TO PROPOSAL STATUS AND/OR SUBMISSION STATUS ON COVER PAGE) ARE PROVIDED "AS IS" TO INTERESTED 10 | PARTIES FOR DISCUSSION ONLY. PARTIES THAT CHOOSE TO IMPLEMENT THIS DRAFT PROPOSAL DO SO AT THEIR OWN RISK. IT IS A DRAFT DOCUMENT AND MAY BE 11 | UPDATED, REPLACED, OR MADE OBSOLETE BY OTHER DOCUMENTS AT ANY TIME. THE FIX GLOBAL TECHNICAL COMMITTEE WILL NOT ALLOW EARLY IMPLEMENTATION TO 12 | CONSTRAIN ITS ABILITY TO MAKE CHANGES TO THIS SPECIFICATION PRIOR TO FINAL RELEASE. IT IS INAPPROPRIATE TO USE FIX WORKING DRAFTS AS 13 | REFERENCE MATERIAL OR TO CITE THEM AS OTHER THAN “WORKS IN PROGRESS”. THE FIX GLOBAL TECHNICAL COMMITTEE WILL ISSUE, UPON COMPLETION OF REVIEW 14 | AND RATIFICATION, AN OFFICIAL STATUS ("APPROVED") OF/FOR THE PROPOSAL AND A RELEASE NUMBER. 15 | 16 | No proprietary or ownership interest of any kind is granted with respect to the FIX Protocol (or any rights therein), except as expressly set out in FIX Protocol Limited's Copyright and Acceptable Use Policy. 17 | 18 | © Copyright 2011-2021 FIX Protocol Limited, all rights reserved 19 | 20 | \ 21 | 22 | ![](https://i.creativecommons.org/l/by-nd/4.0/88x31.png) 23 | 24 | FIX Technical Standard Specifications by [FIX Protocol Ltd.](https://www.fixtradingcommunity.org/) are licensed under a [Creative Commons Attribution-NoDerivatives 4.0 International License](http://creativecommons.org/licenses/by-nd/4.0/). Based on a work at [https://github.com/FIXTradingCommunity/](https://github.com/FIXTradingCommunity/). 25 | 26 | 27 | 1. 28 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/FIXP.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | echo Compilation started... 4 | # Script is expected to start running in the folder where it is located (together with the source files) 5 | SOURCE="$PWD" 6 | # There is only one disclaimer and style docx file for all FIX Technical Standards and it is stored with the FIX Session Layer 7 | # FIXP Repository has local copies with the specific names and dates of the standard 8 | DISCLAIMER="FIXDisclaimerTechStd.md" 9 | STYLE="FIX_TechStd_Style_MASTER.docx" 10 | TARGET="$SOURCE/target" 11 | YAML="$SOURCE/FIXP.yaml" 12 | FILES="01Introduction.md 02Requirements.md 03CommonFeatures.md 04PointToPointSessionProtocol.md 05MulticastSessionProtocol.md 06SummaryOfSessionMessages.md 07UsageExamples.md 08RulesOfEngagement.md" 13 | WPFOLDER="/wp-content/uploads/2021/04/" 14 | 15 | # Create document version with disclaimer 16 | pandoc "$DISCLAIMER" $FILES -o "$TARGET/docx/FIX_Performance_Session_Layer_V1.0.docx" --reference-doc="$STYLE" --metadata-file="$YAML" --toc --toc-depth=4 17 | echo FIXP document version created 18 | 19 | # Create base online version without disclaimer 20 | pandoc $FILES -s -o "$TARGET/debug/FIXPONLINE.html" -s --metadata-file="$YAML" --toc --toc-depth=2 21 | 22 | # Create separate online versions for production and test website by including appropriate link prefixes 23 | sed 's,img src="media/,img src="https://www.fixtrading.org'$WPFOLDER',g' "$TARGET/debug/FIXPONLINE.html" > "$TARGET/html/FIXPONLINE_PROD.html" 24 | sed s/www.fixtrading.org/www.technical-fixprotocol.org/ "$TARGET/html/FIXPONLINE_PROD.html" > "$TARGET/html/FIXPONLINE_TEST.html" 25 | echo FIXP ONLINE version created for PROD and TEST 26 | 27 | echo Compilation ended! 28 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/FIXP.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | title: FIX Performance Session Layer (FIXP) 3 | subtitle: Technical Specification 4 | author: 5 | - "Version 1.0 -- Technical Standard -- April 15, 2021" 6 | - "\x0D" 7 | - "THIS DOCUMENT IS THE FINAL VERSION OF A FIX TECHNICAL STANDARD. THIS VERSION HAS BEEN" 8 | - "APPROVED BY THE GLOBAL TECHNICAL COMMITTEE AS THE FINAL STEP IN CREATING A NEW FIX" 9 | - "TECHNICAL STANDARD OR A NEW VERSION OF AN EXISTING FIX TECHNICAL STANDARD. POTENTIAL" 10 | - "ADOPTERS ARE STRONGLY ENCOURAGED TO USE ONLY THE FINAL VERSION. EXISTING ADOPTERS ARE" 11 | - "STRONGLY ENCOURAGED TO UPGRADE TO THE FINAL VERSION." 12 | --- 13 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/FIX_TechStd_Style_MASTER.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/FIX_TechStd_Style_MASTER.docx -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/media/FlowFinalization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/media/FlowFinalization.png -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/media/Idempotent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/media/Idempotent.png -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/media/Retransmission.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/media/Retransmission.png -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/media/RetransmissionReject.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/media/RetransmissionReject.png -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/media/RetransmitViolation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/media/RetransmitViolation.png -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/media/SessionEstablishment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/media/SessionEstablishment.png -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/media/SessionNegotiation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/media/SessionNegotiation.png -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/media/UnbindTransport-TCP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/media/UnbindTransport-TCP.png -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/media/UnbindTransport-UDP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/media/UnbindTransport-UDP.png -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/media/image1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/media/image1.jpeg -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/publication/FIX_Performance_Session_Layer_V1.0.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/publication/FIX_Performance_Session_Layer_V1.0.docx -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/publication/FIX_Performance_Session_Layer_V1.0.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fixp-specification/af0e9d7eca87b2b7a9a1ace996dd3076013e37d2/v1-0-STANDARD/doc/publication/FIX_Performance_Session_Layer_V1.0.pdf -------------------------------------------------------------------------------- /v1-1/doc/01Introduction.md: -------------------------------------------------------------------------------- 1 | # Scope 2 | 3 | FIX Performance Session Layer (FIXP) is a “lightweight point-to-point protocol” introduced to provide an open industry standard for high performance computing requirements currently encountered by the FIX Trading Community. FIXP is a derived work. The origin and basis for FIXP are the FIX session layer protocols and protocols designed and implemented by NASDAQ OMX, i.e. SoupTCP, SoupBinTCP, and UFO (UDP for Orders). Every attempt was made to keep FIXP as close to the functionality and behavior of SoupBinTCP and UFO as possible. Extensions and refactoring were performed as incremental improvements. Every attempt was made to limit FIXP to establishing and maintaining a communication session between two end points in a reliable manner, regardless of the reliability of the underlying transport. 4 | 5 | FIXP features: 6 | 7 | - Very lightweight session layer with no restrictions on the application layer 8 | - Encoding independent supporting binary protocols 9 | - Transport independent supporting both stream, datagram, and message-oriented protocols 10 | - Point-to-point as well as multicast patterns, sharing common primitives 11 | - Negotiable delivery guarantees that may be asymmetrical 12 | 13 | # Normative references 14 | 15 | The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. 16 | 17 | ### Related FIX standards 18 | 19 | The FIX Simple Open Framing Header standard governs how messages are delimited and has a specific relationship mentioned in this specification. FIXP interoperates with the other FIX standards at the application and presentation layers, but it is not dependent on them. Therefore, they are considered non-normative for FIXP. 20 | 21 | [Simple Open Framing Header (SOFH)](https://www.fixtrading.org/standards/fix-sofh/), technical specification of a message framing standard for FIX messages. 22 | 23 | [FIX Latest](https://www.fixtrading.org/online-specification/), normative specification of the application layer of the FIX Protocol. 24 | 25 | [FIX Simple Binary Encoding](https://www.fixtrading.org/standards/sbe/), optional encoding standard for FIX messages (presentation layer). 26 | 27 | [Encoding FIX using JSON)](https://www.fixtrading.org/standards/asn1/), optional encoding standard for FIX messages (presentation layer). 28 | 29 | [Encoding FIX using GPB](https://www.fixtrading.org/standards/gpb/), optional encoding standard for FIX messages (presentation layer). 30 | 31 | [Encoding FIX using ASN.1](https://www.fixtrading.org/standards/asn1/), optional encoding standard for FIX messages (presentation layer). 32 | 33 | [FIX-over-TLS (FIXS)](https://www.fixtrading.org/standards/fixs/), security guidelines for using Transport Layer Security (TLS) with FIX. 34 | 35 | ### Dependencies on other standards 36 | 37 | FIXP is dependent on several industry standards. Implementations of FIXP must conform to these standards to interoperate. Therefore, they are normative for FIXP. Other protocols may be used by agreement between counterparties. 38 | 39 | [IEEE 754-2019](https://ieeexplore.ieee.org/document/8766229), *IEEE Standard for Binary Floating-Point Arithmetic* 40 | 41 | [IETF RFC 793](https://tools.ietf.org/html/rfc793), *Transmission Control Protocol (TCP)* 42 | 43 | [IETF RFC 768](https://tools.ietf.org/html/rfc768), *User Datagram Protocol (UDP)* 44 | 45 | [IETF RFC 4122](https://tools.ietf.org/html/rfc4122), *A Universally Unique IDentifier (UUID) URN Namespace* 46 | 47 | [IETF RFC 3629](https://tools.ietf.org/html/rfc3629), *UTF-8, a transformation format of ISO 10646* 48 | 49 | [IETF RFC 6455](https://tools.ietf.org/html/rfc6455), *The WebSocket Protocol* 50 | 51 | # Terms and definitions 52 | 53 | For the purposes of this document, the terms and definitions given in [Internet Engineering Task Force RFC2119](http://www.apps.ietf.org/rfc/rfc2119.html) and the following apply. 54 | 55 | ISO and IEC maintain terminology databases for use in standardization at the following addresses: 56 | 57 | --- ISO Online browsing platform: available at [https://www.iso.org/obp](https://www.iso.org/obp) 58 | 59 | --- IEC Electropedia: available at [https://www.electropedia.org](https://www.electropedia.org) 60 | 61 | ### session 62 | A dialog for exchanging application messages between peers. An established point-to-point session consists of a pair of flows, one in each direction between peers. A multicast session consists of a single flow from the producer to multiple consumers. 63 | 64 | ### flow 65 | A unidirectional stream of messages. Each flow has one producer and one or more consumers. 66 | 67 | ### multicast 68 | A method of sending datagrams from one producer to multiple consumers. 69 | 70 | ### client 71 | Initiator of session. 72 | 73 | ### server 74 | Acceptor of session. 75 | 76 | ### credentials 77 | User identification for authentication. 78 | 79 | ### idempotence 80 | Idempotence means that an operation that is applied multiple times does not change the outcome, the result, after the first time. 81 | 82 | ### IETF 83 | Internet Engineering Task Force. 84 | 85 | ### TCP 86 | Transmission Control Protocol is a set of IETF standards for a reliable stream of data exchanged between peers. Since it is connection oriented, it incorporates some features of a session protocol. 87 | 88 | ### TLS 89 | Transport Layer Security is a set of IETF standards to provide security to a session. TLS is a successor to Secure Sockets Layer (SSL). 90 | 91 | ### UDP 92 | User Datagram Protocol is a connectionless transmission for delivering packets of data. Any rules for a long-lived exchange of messages must be supplied by a session protocol. 93 | 94 | ### WebSocket 95 | An IETF protocol that consists of an opening handshake followed by basic message framing, layered over TCP. May be used with TLS. 96 | 97 | ## Specification terms 98 | 99 | These key words in this document are to be interpreted as described in 100 | [Internet Engineering Task Force RFC2119](http://www.apps.ietf.org/rfc/rfc2119.html). 101 | 102 | These terms indicate an absolute requirement for implementations of the standard: "**must**", or "**required**". 103 | 104 | This term indicates an absolute prohibition: "**must not**". 105 | 106 | These terms indicate that a feature is allowed by the standard but not 107 | required: "**may**", "**optional**". An implementation that does not 108 | provide an optional feature must be prepared to interoperate with one 109 | that does. 110 | 111 | These terms give guidance, recommendation or best practices: 112 | "**should**" or "**recommended**". A recommended choice among 113 | alternatives is described as "**preferred**". 114 | 115 | These terms give guidance that a practice is not recommended: "**should not**" 116 | or "**not recommended**". 117 | -------------------------------------------------------------------------------- /v1-1/doc/02Requirements.md: -------------------------------------------------------------------------------- 1 | # Requirements 2 | 3 | ## Business requirements 4 | 5 | Create an enhanced session protocol that can provide reliable, highly efficient, exchange of messages to support high performance financial messaging, over a variety of transports. 6 | 7 | Protocol shall be fit for purpose for current high message rates, low latency environments in financial markets, but should be to every extent possible applicable to other business domains. There is no reason to limit or couple the session layer to the financial markets / trading business domain without extraordinary reason. 8 | 9 | Support common message flow types: Recoverable, Unsequenced, Idempotent (operations guaranteed to be applied only once), and None (for a one-way flow of messages). 10 | 11 | Protocol shall support asymmetric models, such as market participant to market, in addition to peer-to-peer (symmetric). Allow the communication of messages to multiple receivers (broadcast). 12 | 13 | The session protocol does not require or recommend a specific authentication protocol. Counterparties are free to agree on user authentication techniques that fit their needs. 14 | 15 | ## Technical requirements 16 | 17 | ### Protocol layering 18 | 19 | This standard endeavors to maintain a clear separation of protocol layers, as expressed by the Open Systems Interconnection model (OSI). The responsibilities of a session layer are establishment, termination and restart procedures and rules for the exchange of application messages. 20 | 21 | The protocol shall be independent of message encoding (presentation layer), to provide the maximum utility. Encoding independence applies both to session layer messages specified in this document as well as to application messages. It is simpler if session protocol messages are encoded the same way as application messages, but that is not a requirement of this session protocol. 22 | 23 | Users are free to specify message encodings by agreement with counterparties. FIX provides Simple Binary Encoding as well as mappings of FIX to other high performance encodings such as ASN.1, and Google Protocol Buffers. See the list of related standards above. Other recognized encodings may follow in the future. 24 | 25 | Of necessity, the session protocol makes some adaptations for transport layer protocols used by the session layer since the capabilities of common transports are quite different. In particular, TCP is connection- and stream-oriented and implements its own reliable delivery mechanisms. Meanwhile, UDP is datagram-oriented and does not guarantee delivery in order. Unfortunately, these characteristics bleed across protocol layers. 26 | 27 | ### Security mechanisms 28 | 29 | FIXP does not specify its own security features. Rather, the FIX Trading Community separately issues security requirements and recommendations that may apply to FIXP 30 | and other FIX session protocols. Due to the ever-changing nature of information security, the requirements and recommendations are likely to be updated periodically. In general, it is recommended that FIX traffic be protected by using proven controls specified by the FIX Trading Community. See the [FIX-over-TLS (FIXS)](https://www.fixtrading.org/standards/fixs/) standard. 31 | 32 | The FIX Trading Community is in the process of specifying how to authenticate parties using TLS and optionally using FIX credentials. FIX credentials can be used to authenticate a client after an underlying TLS session has been established. FIXP supports this use case by providing a field for credentials in the FIXP session negotiation handshake. 33 | 34 | ### Low overhead 35 | 36 | Minimum overhead is added to the messages exchanged between peers, using only the strictly necessary control messages. 37 | 38 | By agreement between counterparties, a message framing protocol may be used to delimit messages. This relieves the session layer of application message decoding to determine message boundaries. FIX offers the Simple Open Framing Header standard for framing messages encoded with binary wire formats. See standards references above. 39 | -------------------------------------------------------------------------------- /v1-1/doc/05MulticastSessionProtocol.md: -------------------------------------------------------------------------------- 1 | # Multicast session protocol 2 | 3 | A multicast session conveys messages one way from a publisher to any number of listeners. It is conducted over a connectionless transport such UDP multicast. Multicast session protocol is typically used for publishing market data or common reference information to many consumers. Multiple independent flows may be multiplexed over a shared multicast transport. 4 | 5 | ## Multicast session lifecycle 6 | 7 | Since a multicast transport is connectionless, there is no negotiation or binding or unbinding of the transport as in the point-to-point protocol. Thus, Negotiation and Establishment messages and their respective responses are not used. 8 | 9 | Multicast addresses and publishing schedules must be provided out-of-band to listeners. To capture all messages, listeners must be ready to receive at scheduled times. Publishing continues until the end of a logical flow. 10 | 11 | ### Multicast session establishment 12 | 13 | Like a point-to-point session, a multicast session is identified by a UUID. Each time a session is initiated, a new UUID must be generated, and sequence numbers of subsequent application messages must begin with 1. 14 | 15 | #### Topic message 16 | 17 | To associate a transient UUID to a permanent or semi-permanent classification of messages, a Topic message must be used to initiate a flow. Multiple topics may be published on a transport. 18 | 19 | FlowType = Recoverable | Idempotent 20 | 21 | Valid flow types on a multicast session are: 22 | 23 | - **Recoverable**: Messages are sequenced and recoverable. Since the transport is one-way, RetransmitRequests must be delivered through a separate session, however. 24 | 25 | - **Idempotent**: Messages are sequenced to allow detection of loss, but any missed messages are not recoverable. 26 | 27 | Each Topic carries a Classification for the flow to associate it to a permanent or semi-permanent application layer entity. Typical classifications are product types, market symbols or the like. 28 | 29 | To support late joiners, Topic messages should be repeated at regular intervals on a session. This specification does not dictate a specific interval, but the shorter the interval, the less time it takes for a late joiner to identify flows. It is recommended that Topic message be sent with Session heartbeats when the session is otherwise idle. See the session heartbeat section below. 30 | 31 | **Topic** 32 | 33 | | **Field name** | **Type** | **Required** | **Value** | **Description** | 34 | |----------------|----------|:------------:|-----------|-----------------| 35 | | MessageType | Enum | Y | Topic | | 36 | | SessionId | UUID | Y | | Session Identifier | 37 | | Flow | FlowType Enum | Y | | Type of flow from publisher | 38 | | Classification | Object | Y | | Category of application messages that follow | 39 | 40 | ### Finalizing a multicast session 41 | 42 | Finalization ends a logical flow when there are no more application messages to send. A multicast flow should be finalized by transmitting a FinishedSending message. No further messages should be sent, and the session ID is no longer valid after that. 43 | 44 | ## Idempotent flow over multicast 45 | 46 | The goal of an idempotent flow over multicast is to provide at-most-once delivery guarantee to each consumer. Unlike a point-to-point session, however, there is no opportunity to return a NotApplied message to the producer over a one-way transport if a sequence number gap is detected. Therefore, on a multicast, an idempotent flow provides a means to detect data loss, but no direct way to notify the producer or initiate recovery. 47 | 48 | An idempotent flow is implemented by the producer in the same way over a multicast transport as for point-to-point over UDP unicast. Each datagram must begin with either a Sequence message if non-multiplexed or a Context message if the flow is sent over a multiplexed transport. 49 | 50 | ## Session heartbeat 51 | 52 | During the lifetime of a multicast session, its publisher should send Sequence or Context messages as a heartbeat at regular intervals when the session is otherwise inactive. This allows a receiver to tell whether a session is live and has not reached the end of its logical flow. If only a single Topic is published, then Sequence message may be used for heartbeats since there is no context switch. If multiple topics are published on a shared multicast transport, then Context must be used. See [Common features](#common-features) above for a description of sequence numbering and the Sequence and Context messages. 53 | 54 | In addition to the Sequence or Context message, it is recommended that a Topic message should be published on the heartbeat interval. This provides an opportunity for late joiners to gather session characteristics during every idle period. 55 | -------------------------------------------------------------------------------- /v1-1/doc/06SummaryOfSessionMessages.md: -------------------------------------------------------------------------------- 1 | # Summary of session messages 2 | 3 | ## FIXP session messages 4 | 5 | | Stage | Message Name | Purpose | Recoverable | Idempotent | Unsequenced / None | Multicast | 6 | |----------------|----------------------|----------------------------------------|:-------------:|:------------:|:------------------:|:---------:| 7 | | Initialization | Negotiate | Initiates session | • | • | • | | 8 | | | NegotiationResponse | Accepts session | • | • | • | | 9 | | | NegotiationReject | Rejects session | • | • | • | | 10 | | | Topic | Announces a flow | | | | • | 11 | | | MessageTemplate | Delivers template | • | • | • | • | 12 | | Binding | Establish | Binds session to transport | • | • | • | | 13 | | | EstablishmentAck | Accepts binding | • | • | • | | 14 | | | EstablishmentReject | Rejects binding | • | • | • | | 15 | | Transferring | Sequence | Initiates a sequenced flow, keep-alive | • | • | | • | 16 | | | Context | Multiplexing | • | • | • | • | 17 | | | UnsequencedHeartbeat | Keep-alive | | | • | | 18 | | | RetransmitRequest | Requests resynchronization | • | | | | 19 | | | Retransmission | Resynchronization | • | | | | 20 | | Unbinding | Terminate[^1] | Unbinds a transport | • | • | • | | 21 | | Finalizing | FinishedSending | Ends a logical flow | • | • | • | • | 22 | | | FinishedReceiving | Ends a logical flow | • | • | • | • | 23 | 24 | [^1]: On WebSocket transport, Close frame is used instead of the Terminate message. 25 | 26 | ## Related application messages 27 | 28 | These optional application messages respond to application messages on an idempotent flow. 29 | 30 | | Stage | Message Name | Purpose | 31 | |--------------|--------------|---------------------------------------------------| 32 | | Transferring | Applied | Acknowledge idempotent operations | 33 | | | NotApplied | Negative acknowledgement of idempotent operations | 34 | 35 | ## Summary of protocol violations 36 | 37 | If any of these violations by a peer is detected, the session should be immediately terminated. Any application messages that cause a violation, such as a message sent after FinishedSending, should be ignored. 38 | 39 | - Sending a session message that is inappropriate to the flow type, such as a Sequence message on an unsequenced flow. See table above. 40 | - Sending an application message on a point-to-point session that is not in established state. That is, prior to an EstablishmentAck message. 41 | - Sending an Establish message without having successfully negotiated a session. That is, a NegotiationResponse message must have been received for the session. 42 | - Sending an application message after logical flow has been finalized with a FinishedSending message. The responder on a point-to-point session may not send an application message after sending a FinishedReceiving message. 43 | - Sending a FinishedReceiving message without having received a FinishedSending message from the peer. 44 | - Sending any application or session message after sending a Terminate message. 45 | - Reusing the session ID of a session that was finalized. (The server may have a practical limit of session history to enforce this rule.) 46 | - Sending a RetransmitRequest message while a retransmission is in progress. 47 | - Sending a RetransmitRequest message with request range out of bounds. That is, it is a violation to request a retransmission of a message with a sequence number that has not been sent yet. 48 | -------------------------------------------------------------------------------- /v1-1/doc/08RulesOfEngagement.md: -------------------------------------------------------------------------------- 1 | # Appendix B -- FIXP Rules of Engagement 2 | 3 | This checklist is an aid to specifying a full protocol stack to be used for communication between counterparties. 4 | 5 | | Stack layer | Client | Server | 6 | |---------------------------------------|----------------------------|-------------| 7 | | **Application Layer** | | | 8 | | Application level recovery supported? | | | 9 | | FIX version | | | 10 | | Service pack | | | 11 | | Extension packs | | | 12 | | **Presentation Layer** | | | 13 | | Message encoding | | | 14 | | Version | | | 15 | | Schema/templates | | | 16 | | Framing | | | 17 | | **Session Layer** | | | 18 | | Supported flow types | | | 19 | | **Security protocols** | | | 20 | | TLS version | | | 21 | | Authentication | | | 22 | | Cipher suites | | | 23 | | **Transport Layer** | | | 24 | | Transports supported | | | 25 | | Other network protocols | | | 26 | -------------------------------------------------------------------------------- /v1-1/doc/FIXDisclaimerTechStd.md: -------------------------------------------------------------------------------- 1 | ::: {custom-style=Disclaimer} 2 | DISCLAIMER 3 | ::: 4 | 5 | THE INFORMATION CONTAINED HEREIN AND THE FINANCIAL INFORMATION EXCHANGE PROTOCOL (COLLECTIVELY, THE "FIX PROTOCOL") ARE PROVIDED "AS IS" AND NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL MAKES ANY REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED, AS TO THE FIX PROTOCOL (OR THE RESULTS TO BE OBTAINED BY THE USE THEREOF) OR ANY OTHER MATTER AND EACH SUCH PERSON AND ENTITY SPECIFICALLY DISCLAIMS ANY WARRANTY OF ORIGINALITY, ACCURACY, COMPLETENESS, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SUCH PERSONS AND ENTITIES DO NOT WARRANT THAT THE FIX PROTOCOL WILL CONFORM TO ANY DESCRIPTION THEREOF OR BE FREE OF ERRORS. THE ENTIRE RISK OF ANY USE OF THE FIX PROTOCOL IS ASSUMED BY THE USER. 6 | 7 | NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL SHALL HAVE ANY LIABILITY FOR DAMAGES OF ANY KIND ARISING IN ANY MANNER OUT OF OR IN CONNECTION WITH ANY USER'S USE OF (OR ANY INABILITY TO USE) THE FIX PROTOCOL, WHETHER DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL (INCLUDING, WITHOUT LIMITATION, LOSS OF DATA, LOSS OF USE, CLAIMS OF THIRD PARTIES OR LOST PROFITS OR REVENUES OR OTHER ECONOMIC LOSS), WHETHER IN TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), CONTRACT OR OTHERWISE, WHETHER OR NOT ANY SUCH PERSON OR ENTITY HAS BEEN ADVISED OF, OR OTHERWISE MIGHT HAVE ANTICIPATED THE POSSIBILITY OF, SUCH DAMAGES. 8 | 9 | **DRAFT OR NOT RATIFIED PROPOSALS** (REFER TO PROPOSAL STATUS AND/OR SUBMISSION STATUS ON COVER PAGE) ARE PROVIDED "AS IS" TO INTERESTED 10 | PARTIES FOR DISCUSSION ONLY. PARTIES THAT CHOOSE TO IMPLEMENT THIS DRAFT PROPOSAL DO SO AT THEIR OWN RISK. IT IS A DRAFT DOCUMENT AND MAY BE 11 | UPDATED, REPLACED, OR MADE OBSOLETE BY OTHER DOCUMENTS AT ANY TIME. THE FIX GLOBAL TECHNICAL COMMITTEE WILL NOT ALLOW EARLY IMPLEMENTATION TO 12 | CONSTRAIN ITS ABILITY TO MAKE CHANGES TO THIS SPECIFICATION PRIOR TO FINAL RELEASE. IT IS INAPPROPRIATE TO USE FIX WORKING DRAFTS AS 13 | REFERENCE MATERIAL OR TO CITE THEM AS OTHER THAN “WORKS IN PROGRESS”. THE FIX GLOBAL TECHNICAL COMMITTEE WILL ISSUE, UPON COMPLETION OF REVIEW 14 | AND RATIFICATION, AN OFFICIAL STATUS ("APPROVED") OF/FOR THE PROPOSAL AND A RELEASE NUMBER. 15 | 16 | No proprietary or ownership interest of any kind is granted with respect to the FIX Protocol (or any rights therein), except as expressly set out in FIX Protocol Limited's Copyright and Acceptable Use Policy. 17 | 18 | © Copyright 2011-2019 FIX Protocol Limited, all rights reserved 19 | 20 | \ 21 | 22 | ![](https://i.creativecommons.org/l/by-nd/4.0/88x31.png) 23 | 24 | FIX Technical Standard Specifications by [FIX Protocol Ltd.](https://www.fixtradingcommunity.org/) are licensed under a [Creative Commons Attribution-NoDerivatives 4.0 International License](http://creativecommons.org/licenses/by-nd/4.0/). Based on a work at [https://github.com/FIXTradingCommunity/](https://github.com/FIXTradingCommunity/). 25 | 26 | 27 | 1. 28 | -------------------------------------------------------------------------------- /v1-1/doc/FIXP.cmd: -------------------------------------------------------------------------------- 1 | echo Compilation started... 2 | :: Script is expected to start running in the folder where it is located (together with the source files) 3 | set SOURCE=%CD% 4 | :: There is only one disclaimer and style docx file for all FIX Technical Standards and it is stored with the FIX Session Layer 5 | :: FIXP Repository has local copies with the specific names and dates of the standard 6 | set DISCLAIMER=FIXDisclaimerTechStd.md 7 | set STYLE=FIX_TechStd_Style_MASTER.docx 8 | set TARGET=%SOURCE%\target 9 | set YAML=%SOURCE%\FIXP.yaml 10 | set FILES=01Introduction.md 02Requirements.md 03CommonFeatures.md 04PointToPointSessionProtocol.md 05MulticastSessionProtocol.md 06SummaryOfSessionMessages.md 07UsageExamples.md 08RulesOfEngagement.md 11 | set WPFOLDER=\wp-content\uploads\2021/04\ 12 | 13 | :: Create FIX document version with disclaimer 14 | pandoc "%DISCLAIMER%" %FILES% -o "%TARGET%\docx\FIX_Performance_Session_Layer_V1.1.docx" --reference-doc="%STYLE%" --metadata-file="%YAML%" --filter pandoc-plantuml --toc --toc-depth=4 15 | echo FIXP document version created for FIX 16 | 17 | :: Create ISO document version with copyright etc. 18 | set ISOYAML=%SOURCE%\FIXP_ISO.yaml 19 | set ISOSTYLE=ISO_TechStd_Style_MASTER.docx 20 | set ISOCOPYRIGHT=ISOCopyright.md 21 | set ISOFOREWORD=ISOForeword.md 22 | set ISOINTRO=ISOIntro.md 23 | :: set ISOBIBLIO=ISOBiblio.md 24 | 25 | pandoc %ISOCOPYRIGHT% %ISOFOREWORD% %ISOINTRO% %FILES% -o "%TARGET%\docx\ISO_FIX_Performance_Session_Layer_V1.1.docx" --reference-doc=%ISOSTYLE% --metadata-file=%ISOYAML% --filter pandoc-plantuml --toc --toc-depth=3 26 | echo FIXP document version created for ISO 27 | 28 | :: Create base online version without disclaimer 29 | :: pandoc $FILES -s -o "$TARGET/debug/FIXPONLINE.html" -s --metadata-file="$YAML" --toc --toc-depth=2 30 | 31 | :: Remove title as it is redundant to page header 32 | :: sed -i '.bak1' '/

/d' "$TARGET/debug/FIXPONLINE.html" 33 | 34 | :: Add header for table of contents 35 | :: sed -i '.bak2' '/