FIX Acceptor

The role of a FIX Acceptor is to:

• Listen to FIX session initiating (Buy-side) counterparties at a designated port.
• Validate and authenticate a FIX session initiating Logon message from its counterparty.
• Declare a FIX session as 'accepted' by sending a counter-Logon message after successful validation and authentication of the session initiating Logon message.
• Reject and terminate the connection in case of failure in validation and authentication of session initiating Logon message.
• Listen to inbound messages in established FIX sessions.
• Close socket connection if the counterparty becomes 'dead'.

FF.FIX Engine's API library makes it easy for you to develop an application that can function like a FIX Acceptor and accept FIX connections from several FIX compliant Buy-side counterparties and hold several FIX sessions simultaneously.

The following diagram presents an architectural view of a FF.FIX Engine based Acceptor application:

A FF.FIX Engine based FIX Acceptor application has the following components:

::FAQ::

1. How do I setup my FIX Acceptor to accept FIX connections?
2. What is the significance of the FixAcceptorHandler callback interface?
3. How does my FIX Acceptor application identify the counterparties that it can accept?
4. Is it possible to make my Acceptor application accept a connection request from a new counterparty, unknown to it during the Init() call?
5. If the Init() call on an Acceptor instance does not provide the server-IP address, which IP address does it use to listen to its counterparties?
6. Does a Start() call of the Acceptor also start all the sessions maintained by the Acceptor?
7. How do I come to know about the acceptance of a new Initiator connection and creation of a new FixSession by the Acceptor?
8. Can I stop the configured counterparties from establishing connections with my Acceptor application?
9. How do I identify all FixSession instances and their current session states?
10. How do I set different messaging rules for different counterparties (Initiator sessions)?
11. How do I logout a particular counterparty without affecting the transactions it made?
12. Does the Acceptor class provide help in order matching?
13. How does my Acceptor application validate the credentials of a session initiating counterparty?
14. How can my Acceptor application know about the change of state of a FixSession maintained by it?
15. How do I use SSL?

Initialize the list of Initiators.
Initialize the database configuration.
Implement FIX Acceptor Handler.
Instantiate and Initialize the Acceptor.

Step 1: Initialize the list of Initiators (Buy-sides)
Initialize the list of Initiators that your FIX Acceptor shall allow by adding a separate AcceptorTargetConfig object for each allowed Initiator counterparty (Buy-side).

For example:

Step 2: Initialize the database configuration
Initialize the database configuration for your FIX Acceptor application as shown in the sample code below:

Step 3: Implement the FIX Acceptor Handler
Implement the callback methods as required. For details, see FIX Acceptor Handler.

Step 4: Instantiate and initialize the Acceptor.

An Acceptor maintains multiple FixSession instances simultaneously on multiple threads. The FF.FIX Engine library does not provide the business logic as it pertains to your organization's specific requirements (back office part). Instead it provides callbacks on different events, which you can further customize as required.

For example, FF.FIX internally uses methods of the FixAcceptorHandler callback interface to notify the application about events in the ongoing sessions. You can develop your order processing functionality based on these callbacks and by overriding the base implementation in the callback methods.

See following code snippet for a typical Acceptor callback handler:

The AcceptorTargetConfigList parameter in the Init() call of an Acceptor contains a list of AcceptorTargetConfig instances. Each instance represents a separate allowed counterparty.

By comparing the information in the session initiating Logon message against the list of AcceptorTargetConfig objects, a FIX Acceptor application identifies the counterparties it can accept. The AcceptorTargetConfig class documentation in the FF.FIX Engine documentation provides details about the values you require to supply.

Yes, you can make such a provision in your Acceptor application using the following function:

For details, see the AcceptorTargetConfig class documentation in the FF.FIX Engine documentation.

If the server IP address is not supplied or an empty string is supplied during the Init() call of an Acceptor, it identifies the list of network interfaces existing on the Acceptor server and selects the first IP address from this list to listen to its counterparties.

The FixSession instances maintained by the Acceptor are started or initiated only after an explicit request from the connecting counterparty. As a first step, the connecting counterparty (session Initiator) establishes the socket connection with the Acceptor application. After establishing the socket connection, the Acceptor application waits for a Logon message (MsgType = A) from the Initiator for a period specified by the InitiatorLogonTimeOut key in the FIX configuration. (XML file). If the Initiator fails to send a Logon message within this period, the Acceptor application closes the socket connection for that session Initiator.

For this purpose the Acceptor class exposes the following events and callbacks:

• NewClientSocketConnectEvent: The Acceptor raises this event on accepting a new socket connection from the counterparty. The creation of a FixSession object is totally dependent on the validation and authentication of the Logon message from the Initiator counterparty. Hence, this event does not imply the creation of a FixSession instance for that counterparty.
• NewFixSessionCreatedEvent: The Acceptor raises this event after successful authentication of the Logon message from the Initiator counterparty and creation of a FixSession instance for that counterparty.
• OnSessionCreation(): The Acceptor invokes this callback method on the FixAcceptorHandler object before the validation of the Logon message received from the counterparty. The FixAcceptorHandler object is supplied as a parameter during the Init() call of the Acceptor. On the contrary, the NewFixSessionCreatedEvent event is raised only after the successful validation and authentication of the Logon message.

Yes, you may require this type of action if the system is under high stress. Without affecting the ongoing sessions, it is possible prohibit your Acceptor application from accepting any new connections and from creating new FixSession instances by setting the AcceptNewConnection property in the Acceptor instance to false.

The Acceptor class creates a FixSessionInfo object for each AcceptorTargetConfig object supplied to it during the Init() call and also for the AcceptorTargetConfig objects added to it at any later stage. You can access the list of FixSessionInfo objects using the following function exposed by the Acceptor:

To identify the current session state for a particular FixSession, you need to pass the TargetCompID value from the corresponding FixSessionInfo object in the following function:

The messaging rules for a session include supported message types and fields, message recovery rules and message validation levels.

The supported message types and fields can be identified using the FixDataDictionary object associated with the FixSession. The FixConfig object that is supplied as a parameter to the AcceptorTargetConfig constructor contains the associated FixDataDictionary object. The FixConfig object also includes the recovery and validation rules for messages.

After supplying different FixConfig objects for different counterparties, you can implement different messaging rules for each FixSession maintained by your Acceptor application.

For details about messaging rules, see FIX Configuration and FIX Data Dictionary.

You can access the FixSession object for a particular session (counterparty) using the following function exposed by the Acceptor class:

Using the retrieved object, you can perform the logout and many other actions. The FixSession class documentation in FF.FIX Engine documentation provides further details on this topic.

The Acceptor class in FF.FIX Engine is provided as a library and its implementation is restricted to abstracting out intricacies of FIX session maintenance and management. The Acceptor can notify the application about Application Messages received from different counterparties through callbacks on the FixAcceptorHandler object supplied during the Init() call of the Acceptor. After this, the application implementation has to appropriately process the received Application Messages, including the messages related to orders.

For details, see FIX Session Handler.

The responsibility of validating the credentials of session initiating counterparties lies with the Acceptor application. On receiving a Logon message from a session initiating counterparty, the Acceptor application invokes the OnLogonMessage callback on the FIXAcceptorHandler.

The following code snippet demonstrates a sample OnLogonMessage callback implementation:

On successful execution of the last statement of above code, the Acceptor raises the NewFixSessionCreatedEvent event to notify the application about new FIX session creation.

On any change in the session state, the Acceptor instance invokes the OnSessionStateChanged(FixSession fixSession, eSessionState sessionState) callback method on the FixAcceptorHandler object. This object is passed to the Acceptor instance as parameter during the Init() call.

The OnSessionStateChanged callback is limited only to the session state change notification. However, the Acceptor application can retrieve a FixSession corresponding to a specific counterparty and can register not only for the SessionStateChange alert but also for other alerts on it.

For example:

Your Acceptor application can use SSL for its FIX connections with counterparties. For this purpose, set the SecurityOptions property of the Acceptor instance to provide SSL support as shown below: