FIX Session

The FIX Protocol specifications define a FIX session as "a bi-directional stream of ordered messages between two parties within a continuous sequence number series." Parties to a single FIX session may use multiple sequential (but not concurrent) physical connections. They can connect and disconnect several times during a single FIX session. The connected parties must agree on when sessions should start and stop.

Two layers in a FIX session

Each FIX session has two layers of activities.

Session Layer:

It deals with administrative tasks like:

Establishment, maintenance and termination of connection with counterparty
Message delivery and recovery of lost messages
Data encoding, integrity and persistence
Addressing and sequencing of messages
Controlling the session behavior through different parameters
Logging of events

Application Layer:

The Application Layer deals with actual business contents and trade related information exchange and processing.

Role of FF.FIX Engine in your application

The entire FF.FIX session layer in FF.FIX Engine is completely automatic and needs no programmatic intervention. FF.FIX Engine completely automates the session layer in FIX sessions and lets you concentrate on the core business functions and logic relevant to your organization for inclusion in the application layer. As FIX developer, you can use the FF.FIX Engine APIs to send application messages to your counterparty, register different session events, monitor FIX session states, monitor FIX connection health and interface with external applications like databases and analysis tools.

The FF.FIX Engine based session layer guarantees the bidirectional, ordered and reliable message exchange with the counterparty's FIX Engine. It not only handles all basic session layer requirements of a FIX session (mentioned above) but also offers you excellent control of the FIX session behavior and its analysis through several customizable parameters like latency checks, message throttling, message recovery rules, customizable validation levels, Adapter Plug-ins technology, interfacing with message and event analysis tools etc.

About the Session Layer

The session layer guarantees the bidirectional, ordered and reliable message delivery. The entire session layer is based on seven messages-Logon, Logout, Heartbeat, TestRequest, ResendRequest, Reject and SequenceReset. These messages and their descriptions are given below.

Message	MsgType (Tag 35)	Description
Logon	A	Establishes the FIX session
Logout	5	Ends the FIX session
Heartbeat	0	Announces that the sender of the message is alive in the session
Test Request	1	Queries whether counterparty is alive in the session
Reject	3	To reject incoming messages (used for low level failures in messages, not for business reasons)
Resend Request	2	Requests to send the lost messages, based on sequence number gaps
Sequence Reset (Gap Fill)	4	To skip over messages

Besides these messages there is a lot of session level logic that FF.FIX Engine automates for you. It includes customizable message recovery rules, GapFill mechanisms, resetting sequence number at occurrence of important events, latency checks, session scheduling, make provision for counterparty specific requirements without affecting the common application code etc.

About the Application Layer

The application layer holds the core business logic and views the session layer as a black box. Since the FIX Protocol deals with all asset classes (stock, futures, derivatives etc.), the application layer messages include messages for order initiation, getting a fill, changing an order, indication of interest, order execution reports, market data publishing and more. The application layer covers all pre-trade, trade and post-trade activities.

Since FF.FIX Engine automates the session layer and provides a rich set of APIs for interfacing with existing trading systems, you can easily implement the business logic relevant to your organization and quickly deploy your application to get a leading edge over your competitors.

Physical and FIX connections

Physical connection: A physical connection means establishing a telecommunication link using a network protocol. The two parties who wish to engage into a FIX session need to physically connect over some suitable telecommunication link using a suitable network protocol that regulates the telecommunication link. This link can be a telephone line, leased line, ISDN, LAN, WAN etc.

FIX connection: After establishing a physical connection, the initiating party sends a Logon message. A FIX connection establishes on acceptance of this Logon message. A FIX connection spans over- [1] session initiation (Logon message), [2] message exchange during the session and [3] session termination (normal termination through a Logout message or abnormal termination by closure of the physical connection).

Establishing a FIX connection

A FIX session establishes on making a successful FIX connection. The steps in establishing a FIX connection are:

A session initiating party sends an initial Logon message over a successfully established physical connection.
The session accepting party receives that Logon request and does the first level validation of the sending party.
On successful validation of the initiating party, the session accepting party accepts the Logon request and acknowledges it with a counter-Logon message to the session initiating party.
The session initiating party receives the counter-Logon message and understands that the FIX connection is established. It then starts exchanging application layer messages with its counterparty. Session layer messages are managed automatically by the FF.FIX Engine based application.

Terminating a FIX connection

The physical connection is the preliminary requirement for a FIX connection. Accordingly, a FIX connection can terminate normally or abnormally as follows:

Normal termination

A party can choose to terminate an ongoing FIX connection by sending a Logout message.
The counterparty then usually acknowledges this Logout message with a counter-Logout message (if there are no message gaps).
The party shuts down the telecommunication link on receiving this counter-Logout message.

Abnormal termination

The FIX connection terminates abnormally due to failures in the physical connection i.e. the telecommunication link.

Duration of physical and FIX connections

The duration of FIX connection is less than the duration of Physical connection. The physical connection is the preliminary requirement for a FIX connection. A party can exchange messages as long as the physical connection is intact. FIX connection span over the period from Logon to Logout/abnormal termination.

Initiator

The Initiator is the party which establishes a physical connection with the counterparty and initiates the session via transmission of an initial Logon message. If the initial Logon message is unsuccessful, the initiator needs to reconnect.

Acceptor

The Acceptor is the party which validates connection requests (Logon messages) from multiple counterparties and sends counter-Logon message as an acknowledgement to the accepted counterparties.

The Acceptor always listens at a predefined physical port for incoming connections and messages.

Note:
Prior to sending the counter-Logon message, the Acceptor does the first level validation of the incoming Logon message. If the message complies with the agreed specifications, then only the Acceptor sends the counter-Logon message. Else, the Acceptor sends a Reject message or simply shuts down the physical connection with the counterparty, depending upon its system settings.

FIX connection and FIX session

A FIX session is a superset of FIX connections. A single FIX session can span over multiple FIX connections because:

The parties may break their FIX connection after trading hours or
the FIX connection can abnormally break due to failure of the physical communication link.

The duration of a FIX connection is from Logon to Logout only. However, over a single FIX session, there can be multiple instances of Logon to Logout messages.

Concentrate mainly on Body of Application Messages

Each FIX Message, related to session layer as well as application layer, has three blocks- Header, Body and Trailer. The Header and Trailer of each message contain the crucial information for primary validation of messages and performing session layer related tasks. The Body of session layer messages (Admin Messages) also includes the information relevant to session layer logic. Only the Body of application layer messages (Application Messages) includes the information relevant to the trade. FF.FIX Engine enables you to concentrate on the logic for the Body part of Application Messages mainly.

::FAQ::

What is the role of the FixSession class?
How do I get the current state of the FIX session?
How do I extract the connection information of the counterparty?
How do I extract different parameters associated with a FIX session?
How do I get alerts for different events and session state changes during a FIX session?

What is the role of the FixSession class?

The FixSession class in FF.FIX Engine manages the FIX session between the Initiator and Acceptor applications. The objects of FixSession class are not directly created. These objects are accessible through FF.FIX Engine based Initiator/Acceptor application.

FIX session states

The states of a FIX session are the states of the FixSession object. At a given time it is in one of the following states:

Session state	Description
Disconnected	eSessionState.Disconnected: After creation of the FixSession object, the FIX session is in disconnected state. When there is an unexpected error or if the physical connection brakes down, the FixSession state changes to eSessionState.Disconnected. It means that application has no wired connection with the counterparty.
Connecting	eSessionState.Connecting: When the Initiator application tries to establish a socket connection, the FixSession state changes to eSessionState.Connecting.
Connected	eSessionState.Connected: After the physical connection to Acceptor is established the FixSession state changes to eSessionState.Connected.
Logging	eSessionState.Logging: After establishing the physical connection to Acceptor, the Initiator sends the Login message. This changes the FixSession state to eSessionState.Logging.
Logged	eSessionState.Logged: When the Acceptor accepts the Logon message and acknowledges it with the counter-Logon message, the FixSession state changes to eSessionState.Logged. The parties exchange FIX Messages while they are in logged state.
LoggingOut	eSessionState.LoggingOut: On sending a Logout message to terminate the session, the FixSession state changes to eSessionState.LoggingOut.
LoggedOut	eSessionState.LoggedOut: On confirmation of Logout message with counter-Logon message, the FixSession state changes to eSessionState.LogginOut.
Disconnecting	eSessionState.Disconnecting: The FixSession state changes to eSessionState.Disconnecting while it is in the process of shutting down the physical connection.

FIX session state change alerts

You may access the FixSession state change by registering to the SessionStateChanged event of FixSession object. See the following code:

FixSession fixSession;
...
...

If(fixSession != null)
{
fixSession.SessionStateChanged += new FixSessionStateChangedEventHandler(OnSessionStateChanged);
}
...

private void OnSessionStateChanged(FixSession fixSession, eSessionState currentSessionState, eSessionState previousSessionState)
{
System.Console.WriteLine("New FIX session state is: " + currentSessionState.ToString());
}

Sending Application Messages from FixSession object

One of the important methods of the FixSession is the SendMessage method, used to send a custom Application Message to the counterparty. For example,

FixMessage orderMessage = GetNewOrderMessage();
fixSession.SendMessage(orderMessage);

How do I get the current state of the FIX session?

See the following code:

FF.Fix.Core.Session.eSessionState sessionState = fixSession.GetSessionState();

How do I extract the connection information of the counterparty?

See the following code:

string ipAddress = fixSession.ClientIPEndPoint;
System.Net.IPEndPoint ipEndPoint = fixSession.ClientConnectionEndPoint;

How do I extract different parameters associated with a FIX session?

The objects of FixSession provide many APIs to extract different parameters. For example,

//Getting the date and time of session-start.
DateTime sessionStartDate = fixSession.SessionStartedDT;

//Getting the heartbeat interval
Int heartBtIntInterval = fixSession.HeartBtInt;

How do I get alerts for different events and session state changes during a FIX session?

The AlertManager enables your application to listen to alert notifications on different events and changing states of the FixSession object. The following table lists different alert types.

Error: This alert is raised whenever an error occurs in the FixSession.
Alert Message	Error message.
Additional Message	Additional information pertaining to the error.
InboundMessage: This alert is raised whenever a new message is received from the counterparty.
Alert Message	Raw FIX Message string.
Additional Message	The latency time calculated from the sending time contained in the FIX Message.
InboundMessageSeqNumber: This alert is raised whenever the FixSession updates the next expected Inbound Message sequence number from the counterparty.
Alert Message	Sequence number (MsgSeqNum [tag 34]) of the last received FIX Message from the counterparty.
AdditionalMessage	Empty string.
Info: Retained for extension.
Alert Message
Additional Message
OutboundMessage: This alert is raised whenever a new message is successfully sent to the counterparty.
Alert Message	Raw FIX Message string.
Additional Message	Empty string.
OutboundMessageSeqNumber: This alert is raised every time the FixSession updates the Outbound Message sequence number from the counterparty.
Alert Message	Sequence number of the last FIX Message sent to the counterparty.
Additional Message	Empty string.
SessionStateChange: This alert is raised whenever the state of FixSession changes.
Alert Message	Current session state string.
Additional Message	Empty string

For example,

//Register to listen all session alerts
_fixSession.GetAlertManager().RegisterAlertCallback(FF.Fix.Core.eAlertType.All, new AlertCallbackRoutine(OnFIXSesssionAlertMessage));
...
...
...

private void OnFIXSesssionAlertMessage(SessionInfo fixSessionInfo, eAlertType alertType, string alertMessage, string additionalMessage)
{
    if (alertType == eAlertType.InboundMessageSeqNumber)
    {
        SetControlText(this.txtInboundSequenceNumber, alertMessage);
    }
    else if (alertType == eAlertType.OutboudMessageSeqNumber)

    {
        SetControlText(this.txtOutboundSequenceNumber, alertMessage);
    }
    else if (alertType == eAlertType.InboundMessage)

    {
        SetControlText(this.rtbMessageLog, "INBOUND MESSAGE: " + alertMessage);
    }
    else if (alertType == eAlertType.OutboudMessage)

    {
        SetControlText(this.rtbMessageLog, "OUTBOUND MESSAGE: " + alertMessage);
    }
    else if (alertType == eAlertType.SessionStateChange)

    {
        SetControlText(this.txtSessionState, alertMessage);
    }
    else if (alertType == eAlertType.Info || alertType == eAlertType.Error || alertType
    == eAlertType.Warning)

    {
        SetControlText(this.rtbLog, alertType.ToString().ToUpper() + ": " + alertMessage);
    }
}