What is FIXP?
FIX Performance Session Layer (FIXP) is a lightweight protocol that describes how to establish and maintain a communication session between two endpoints. Its main goal is to provide a reliable and highly efficient exchange of financial messages over a variety of transports.
FIXP is developed by the High-Performance Working Group of the FIX Trading Community.
The main features of FIXP include
- Low overhead session layer
- No restriction on the application layer (no session-level fields are required in application messages)
- Encoding independent, message binary wire format (for example, SBE, Google Protocol Buffer) is agreed between counterparties
- Transport independent (both stream and datagram protocols are supported)
- Negotiable message delivery guarantees
FIXP does not specify security features, counter-parties agree on user authentication techniques.
A message framing protocol (for example, “Simple Open Framing Header”) may be used to delimit messages by agreement between counter-parties.
FIXP technical standard features include
Each FIXP session must be identified by a unique Session ID encoded as a UUID version 4 (RFC 4122) assigned by the client (for example, f81d4fae-7dec-11d0-a765-00a0c91e6bf6).
A session identifier must be unique for all time.
Sequence numbering is used for ordered delivery and message recovery. Only application messages are sequenced. A session-level message is used to start a sequenced flow of application messages.
A FIXP session is established between counter-parties and lasts until message flows between them are complete.
Timing for session start and end are agreed between counter-party.
A logical FIXP session is identified by a Session ID and can span over several sequential transport connections. When an existing session is re-established, its original Session ID is used, and messages that were lost during the disconnect may be recovered.
Message Flow Types
A message flow is a stream of application messages in one direction.
FIXP supports configurable delivery guarantees for each flow:
- Recoverable: exactly-once message delivery. If message gaps are detected, then missed messages may be recovered by retransmission.
- Idempotent: at-most-once delivery. If message gaps are detected, the sender is notified, but recovery is under control of the application.
- Unsequenced: no delivery guarantees (best-effort).
- None: one-way flow of messages. All application messages should be sent in one direction of the session.
A bi-directional session may have asymmetrical message flows (e.g., the exchange flow could be Recoverable, and the client flow could be Idempotent).