/n Documentation

Creating an Application

Get your DLLs

Starting with v1.9.0, your project will need at least 2 QuickFIX/n dlls:
  1. The core: QuickFix.dll
  2. The message definitions for the FIX version(s) you’re using, which will be one or more of:
  • QuickFix.FIX40.dll
  • QuickFix.FIX41.dll
  • QuickFix.FIX42.dll
  • QuickFix.FIX43.dll
  • QuickFix.FIX44.dll
  • QuickFix.FIX50.dll
  • QuickFix.FIX50SP1.dll
  • QuickFix.FIX50SP2.dll
All of these are in the release zip   (If you built QF/n from source, then you’ll find these dlls in Messages\FIX<n>\bin\)   Most applications only need to support one FIX version.

Creating your Application

Creating a FIX application is easy; simply implement an IApplication:  
public class  IApplication
{
    public void FromApp(Message msg, SessionID sessionID) { }
    public void OnCreate(SessionID sessionID) { } 
    public void OnLogout(SessionID sessionID) { }
    public void OnLogon(SessionID sessionID) { }
    public void FromAdmin(Message msg, SessionID sessionID) { }
    public void ToAdmin(Message msg, SessionID sessionID) { }
    public void ToApp(Message msg, SessionID sessionID) { }
}
These methods will be called on QuickFIX/N events. We’ll explain what each callback does next.

Application Callbacks

The callbacks in a QuickFIX/N application notify us of events - when a counterparty logs on, when admin messages are sent, and most importantly, when application messages are received.

FromApp - every inbound application level message will pass through this method, such as orders, executions, security definitions, and market data.
FromAdmin - every inbound admin level message will pass through this method, such as heartbeats, logons, and logouts.
OnCreate - this method is called whenever a new session is created.
OnLogon - notifies when a successful logon has completed.
OnLogout - notifies when a session is offline - either from an exchange of logout messages or network connectivity loss.
ToApp - all outbound application level messages pass through this callback before they are sent. If a tag needs to be added to every outgoing message, this is a good place to do that.
ToAdmin - all outbound admin level messages pass through this callback.

Better Type Safety

We highly recommend implementing the Receiving Messages tutorial to receive more type safe messages.

Initiators and Acceptors

QuickFIX/N implements both the initiator and acceptor pattern in FIX.

Initiator is the FIX term for client - we use an Initiator when we are connecting to another party.

Acceptor is the FIX term for server - we use an Acceptor when other parties are connecting to us.

Creating Our Application

Putting it all together, we implement the Application interface then instantiate an Acceptor:


using QuickFix;

public class MyQuickFixApp : IApplication
{
    public void FromApp(Message msg, SessionID sessionID) { }
    public void OnCreate(SessionID sessionID) { }
    public void OnLogout(SessionID sessionID) { }
    public void OnLogon(SessionID sessionID) { }
    public void FromAdmin(Message msg, SessionID sessionID) { }
    public void ToAdmin(Message msg, SessionID sessionID) { }
    public void ToApp(Message msg, SessionID sessionID) { }
}

public class MyApp
{
    static void Main(string[] args)
    {
        SessionSettings settings = new SessionSettings(args[0]);
        IApplication myApp = new MyQuickFixApp();
        IMessageStoreFactory storeFactory = new FileStoreFactory(settings);
        ILogFactory logFactory = new FileLogFactory(settings);
        ThreadedSocketAcceptor acceptor = new ThreadedSocketAcceptor(
            myApp,
            storeFactory,
            settings,
            logFactory);

        acceptor.Start();
        while (true)
        {
            System.Console.WriteLine("o hai");
            System.Threading.Thread.Sleep(1000);
        }
        acceptor.Stop();
    }
}

Please view the Receiving Messages tutorial to see how to implement type safe message callbacks. This is highly recommended.


Switching this to an Initiator is as simple as swapping out the ThreadedSocketAcceptor class for the SocketInitiator class.


The IMessageStore keeps a record of all outgoing messages for FIX session level messaging. We could implement our own store by implementing the MessageStoreFactory interface.


There are a few options for logging, with file logger probably being the most useful. We could also implement our own logger by implementing the ILogFactory interface.

Sending Messages

Sending Messages

Sending FIX messages in QuickFIX/N is simple:


FIX44.NewOrderSingle order = new FIX44.NewOrderSingle(
    new ClOrdID("1234"),
    new Symbol("AAPL"),
    new Side(Side.BUY),
    new TransactTime(DateTime.Now),
    new OrdType(OrdType.MARKET));

Session.SendToTarget(order, sessionID);

First, we need to learn how to direct messages with Sessions.

QuickFIX Sessions

When sending a message, we must tell QuickFIX which Session to send it to.

All QuickFIX Sessions are identified by fields in the header of a message, usually SenderCompID, TargetCompID, and BeginString. These are specified in the config file.

SenderCompID=CONNAMARA
TargetCompID=CBOE
BeginString=FIX.4.4

There are a few patterns to gather the session. We can grab the SessionID when it is created and cache it:

private SessionID MySessionID { get; set; }
public void OnCreate(SessionID sessionID)
{
    MySessionID = sessionID;
}

We can get the SessionID when responding to an incoming message:

public void OnMessage(FIX42.ExecutionReport execution, SessionID sessionID) 
{
    ProcessExecution(execution, sessionID);
}

Or, we can construct a SessionID by matching the values from our config file:

var mySessionID = new SessionID("FIX4.4", "CONNAMARA", "CBOE");

Creating and Sending a Message

The preferred constructor to use includes the specific FIX version and message type. We also pass in the required fields:

import QuickFix;
import QuickFix.Fields;

var order = new QuickFix.FIX44.NewOrderSingle(
    new ClOrdID("1234"),
    new Symbol("AAPL"),
    new Side(Side.BUY),
    new TransactTime(DateTime.Now),
    new OrdType(OrdType.LIMIT));

To set fields, use the message’s field properties:

order.Price = new Price(new decimal(22.4));
order.Account = new Account("18861112");

Putting it all together - creating the message, setting its required fields, setting two additional fields, using SessionID from the section above, we send the message on its way:

var order = new QuickFix.FIX44.NewOrderSingle(
    new ClOrdID("1234"),
    new Symbol("AAPL"),
    new Side(Side.BUY),
    new TransactTime(DateTime.Now),
    new OrdType(OrdType.LIMIT));

order.Price = new Price(new decimal(22.4));
order.Account = new Account("18861112");

Session.SendToTarget(order, sessionID);

Alternative Constructors and Field Setters

The type safe way – the best way – was demonstrated above, but there are a few other ways to create messages and set fields.

Each message type has a default constructor:

var order = new QuickFix.FIX44.NewOrderSingle();
order.ClOrdID =  new ClOrdID("1234");
order.Symbol = new Symbol("AAPL");
order.Side = new Side(Side.BUY);

We have the QuickFIX C++ and QuickFIX/J style get/set methods available, which are also type safe:

order.Set(new TransactTime(DateTime.Now));
order.Set(new OrdType(OrdType.LIMIT));

For setting a field that isn’t a property of a message, use setField:

order.SetField(new Account("18861112"));

Here we create base Message class; it has no properties so SetField must be used everywhere. This style is not recommended:

var order = new QuickFix.Message();
order.Header.SetField(new MsgType("D"));
order.SetField(new ClOrdID("1234"));
order.SetField(new Symbol("AAPL"));
order.SetField(new Side(Side.BUY));
order.SetField(new TransactTime(DateTime.Now));
order.SetField(new OrdType(OrdType.LIMIT));

Receiving Messages

Receiving Messages

Receiving messages in QuickFIX/N is type safe and simple:

public void OnMessage(
    QuickFix.FIX44.NewOrderSingle order, 
    SessionID sessionID)
{
    ProcessOrder(order.Price, order.OrderQty, order.Account);
}

Receiving Type Safe Messages

The best way to write an app is with the specific, strongly typed Message and Field classes, which we’ll mixin with MessageCracker. We import the MessageCracker class, inherit from it, then call Crack inside FromApp:

using QuickFix;

public class MyApplication : MessageCracker, IApplication
{
    public void FromApp(Message msg, SessionID sessionID)
    {
        Crack(msg, sessionID);
    }
    //...
}

Crack will then call the appropriate overloaded OnMessage callback. This example receives orders and security definitions:

public void OnMessage(
    QuickFix.FIX44.NewOrderSingle ord, 
    SessionID sessionID)
{
    ProcessOrder(ord.Price, ord.OrderQty, ord.Account);
}

public void OnMessage(
    QuickFix.FIX44.SecurityDefinition secDef, 
    SessionID sessionID)
{
    GotSecDef(secDef);
}

Example Message Cracker

Putting it all together, a full application with type safe orders looks like this:

public class MyApplication : MessageCracker, IApplication
{
    public void OnMessage(
        QuickFix.FIX42.NewOrderSingle ord,
        SessionID sessionID)
    {
        ProcessOrder(ord.Price, ord.OrderQty, ord.Account);
    }

    protected void ProcessOrder(
        Price price,
        OrderQty quantity,
        Account account)
    {
        //...
    }

    #region Application Methods

    public void FromApp(Message msg, SessionID sessionID)
    {
        Crack(msg, sessionID);
    }
    public void OnCreate(SessionID sessionID) { }
    public void OnLogout(SessionID sessionID) { }
    public void OnLogon(SessionID sessionID) { }
    public void FromAdmin(Message msg, SessionID sessionID)
    { }
    public void ToAdmin(Message msg, SessionID sessionID)
    { }
    public void ToApp(Message msg, SessionID sessionID)
    { }

    #endregion
}

Less Type Safe

It is possible to receive message callbacks with only the base class Message.

This is not recommended - we lose the typesafe Group and Field properties and extra boilerplate logic is required:

// NOT RECOMMENDED
public class MyApplication : IApplication
{
    public void FromApp(Message msg, SessionID sessionID)
    {
        string msgType = msg.Header.GetString(Tags.MsgType);
        if (msgType.Equals(MsgType.EXECUTION_REPORT))
        {
          string account = msg.GetString(Tags.Account);
          decimal price = msg.GetDecimal(Tags.Price);
        }
    }
    // ...same Application callbacks as above
}

Repeating Groups

QuickFIX/N creates and reads repeating groups in FIX messages.

Creating Groups

Creating groups is straightforward - instantiate the specific group class then add it to the message:

var tcr = new QuickfiFix.FIX44.TradeCaptureReport();
var sidesGrp1 = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup();
sidesGrp1.Account = new Account("Silvio");
sidesGrp1.OrderID = new OrderID("09011900");
sidesGrp1.Side = new Side(Side.BUY);

var sidesGrp2 = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup();
sidesGrp2.Account = new Account("Sven");
sidesGrp2.OrderID = new OrderID("2000");
sidesGrp2.Side = new Side(Side.BUY);

tcr.AddGroup(sidesGrp1);
tcr.AddGroup(sidesGrp2);

We can create groups inside of groups, too:

var tcr = new QuickFix.FIX44.TradeCaptureReport();
var sidesGrp = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup();
sidesGrp.Side = new Side(Side.BUY);
sidesGrp.Account = new Account("Piola");
sidesGrp.OrderID = new OrderID("09011900");
var partyIdsGrp = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup.NoPartyIDsGroup();
partyIdsGrp.PartyID = new PartyID("Nesta13");
sidesGrp.AddGroup(partyIdsGrp);
tcr.AddGroup(sidesGrp);

Reading Groups

To read a group from a message, we use GetGroup() and supply a reference to a new group object of the appropriate type. The extracted group gets assigned to this parameter.

var sidesGrp1 = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup();
tcr.GetGroup(1, sidesGrp1);
// sidesGrp1 now has all fields populated
var sidesGrp2 = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup();
tcr.GetGroup(2, sidesGrp2);

Group indexes start at 1.

To iterate the groups, we can use a for loop with the value of the group field:

var noSidesGrp = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup();
for(int grpIndex = 1; grpIndex<= message.GetInt(Tags.NoSides); grpIndex += 1)
{
    message.GetGroup(grpIndex, noSidesGrp);
    // ...do stuff with noSidesGrp...
}

Configuration

Configuring QuickFIX/N

An acceptor or initiator can maintain as many FIX sessions as you would like. A FIX session is defined in QuickFix/N as a unique combination of a BeginString (the FIX version number), a SenderCompID (your ID), and a TargetCompID (the ID of your counterparty). A SessionQualifier can also be used to disambiguate otherwise identical sessions.


Each session can have several settings associated with them. Some of these settings may not be known at compile time and are therefore passed via a class called SessionSettings. SessionSettings behaves as a data dictionary that can be set and queried.


The SessionSettings class has the ability to parse settings out of any System.IO.TextReader. You can also simply pass it a filename. If you decide to write your own components (eg, storage for a particular database) you may also use this to store settings.


A settings file is set up with two types of heading; [DEFAULT] and [SESSION]. [SESSION] tells QuickFIX/N that a new Session is being defined. [DEFAULT] is a section to define settings which will be associated with sessions that don’t explicitly define them. QuickFIX/N itself will not define default values for all required settings. If you do not provide a setting that QuickFIX/N needs, it will throw a ConfigError telling you what setting is missing or improperly formatted.


Below are the settings that can be associated with a session based on the default functionality provided with QuickFIX/N, followed by an example.

Session

Setting Description Valid Values Default
BeginString Version of FIX this session uses
FIXT.1.1
FIX.4.4
FIX.4.3
FIX.4.2
FIX.4.1
FIX.4.0
SenderCompID Your ID as associated with this FIX session case-sensitive alpha-numeric string
SenderSubID (Optional) Your subID as associated with this FIX session case-sensitive alpha-numeric string
SenderLocationID (Optional) Your locationID as associated with this FIX session case-sensitive alpha-numeric string
TargetCompID Counterparty's ID as associated with this FIX session case-sensitive alpha-numeric string
TargetSubID (Optional) Counterparty's subID as associated with this FIX session case-sensitive alpha-numeric string
TargetLocationID (Optional) Counterparty's locationID as associated with this FIX session case-sensitive alpha-numeric string
SessionQualifier Additional qualifier to disambiguate otherwise identical sessions case-sensitive alpha-numeric string
DefaultApplVerID Required only for FIXT 1.1 (and newer). Ignored for earlier transport versions. Specifies the default application version ID for the session. This can be the ApplVerID enum (see the ApplVerID field) or the BeginString for the default version.
FIX.5.0SP2
FIX.5.0SP1
FIX.5.0
FIX.4.4
FIX.4.3
FIX.4.2
FIX.4.1
FIX.4.0
-
ConnectionType Defines if session will act as an acceptor or initiator
initiator
acceptor
-
StartTime Time of day that this FIX session becomes activated Time in the format of HH:MM:SS. Uses "TimeZone" if specified, else UTC -
EndTime Time of day that this FIX session becomes deactivated Time in the format of HH:MM:SS. Uses "TimeZone" if specified, else UTC -
StartDay For week long sessions, the starting day of week of the session. Use in combination with StartTime. Day of week in English using any abbreviation (ie mo, mon, mond, monda, monday are valid) -
EndDay For week long sessions, the ending day of week for the session. Use in combination with EndTime. Day of week in English using any abbreviation (ie mo, mon, mond, monda, monday are valid) -
MillisecondsInTimeStamp Determines if milliseconds should be added to timestamps. Only available for FIX.4.2 and greater.
Y
N
Y
SendRedundantResendRequests If set to Y, QuickFIX will send all necessary resend requests, even if they appear redundant. Some systems will not certify the engine unless it does this. When set to N, QuickFIX will attempt to minimize resend requests. This is particularly useful on high volume systems.
Y
N
N
ResetOnLogon Determines if sequence numbers should be reset when receiving a logon request. Acceptors only.
Y
N
N
ResetOnLogout Determines if sequence numbers should be reset to 1 after a normal logout termination.
Y
N
N
ResetOnDisconnect Determines if sequence numbers should be reset to 1 after an abnormal termination
Y
N
N
RefreshOnLogon Determines if session state should be restored from persistence layer when logging on. Useful for creating hot failover sessions.
Y
N
N
EnableLastMsgSeqNumProcessed Add the last message sequence number processed in the header (optional tag 369).
Y
N
N
MaxMessagesInResendRequest Sets the maximum number of messages to retransmit in a single resend request. Any integer greater than 0 is valid. Use 0 for infinity (default). 0
SendLogoutBeforeDisconnectFromTimeout Specifies whether a logout message should be sent before a connection is disconnected due to a timeout.
Y
N
N
IgnorePossDupResendRequests Specifies whether to ignore a resend request when PossDupFlag (tag 43) is set to true
Y
N
N
UseLocalTime Specifies whether to use local machine time for session schedule (StartTime and EndTime).
Y
N
N
TimeZone Specifies time zone ID used for session schedule. Cannot be used with UseLocalTime. Supplied ID will be passed to TimeZoneInfo.FindSystemTimeZoneById. (See here for how to get a list of valid IDs on your system.) Any time zone ID supported on target system. -
RequiresOrigSendingTime If N, do not reject SequenceReset/PossDup messages that lack OrigSendingTime
Y
N
Y

Validation

Setting Description Valid Values Default
UseDataDictionary Tells session whether or not to expect a data dictionary. You should always use a DataDictionary if you are using repeating groups.
Y
N
Y
DataDictionary
XML definition file for validating incoming FIX messages. If no DataDictionary is supplied, only basic message validation will be done.

This setting should only be used with FIX transport versions older than FIXT.1.1 (i.e. FIX4x). See TransportDataDictionary and AppDataDictionary for FIXT.1.1 (i.e. FIX5+) settings.
Valid XML data dictionary file. QuickFIX/N comes with the following defaults in the spec/fix directory

FIX44.xml
FIX43.xml
FIX42.xml
FIX41.xml
FIX40.xml
-
TransportDataDictionary
XML definition file for validating admin (transport) messages. This setting is only valid for FIXT.1.1 (usually FIX5+) sessions.

See DataDictionary for older transport versions (FIX.4.0-FIX.4.4) for additional information.
Valid XML data dictionary file. QuickFIX/N comes with the following defaults in the spec/fix directory

FIXT1.1.xml
-
AppDataDictionary
XML definition file for validating application messages. This setting is only valid for FIXT.1.1 (usually FIX5+) sessions.

Not used for older transport versions. For FIX4x versions, see the DataDictionary setting.

This setting supports the possibility of a custom application data dictionary for each session. This setting can be used as a prefix to specify multiple application dictionaries for the FIXT transport. For example:

DefaultApplVerID=FIX.4.2
# For default application version ID
AppDataDictionary=FIX42.xml
# For nondefault application version ID
# Use BeginString suffix for app version
AppDataDictionary.FIX.4.4=FIX44.xml
Valid XML data dictionary file, QuickFIX/N comes with the following defaults in the spec/fix directory

FIX50SP2.xml
FIX50SP1.xml
FIX50.xml
FIX44.xml
FIX43.xml
FIX42.xml
FIX41.xml
FIX40.xml
-
ValidateLengthAndChecksum If set to N, messages with incorrect length or checksum fields will not be rejected.
Y
N
Y
ValidateFieldsOutOfOrder If set to N, fields that are out of order (ie, body fields in the header, or header fields in the body) will not be rejected. Useful for connecting to systems which do not properly order fields.
Y
N
Y
ValidateFieldsHaveValues If set to N, fields without values (e.g. "|44=|"; nothing after the "=") will not be rejected. Useful for connecting to systems that improperly send empty tags.
Warning: The QF/n engine will not try to convert empty strings to non-string types.
For instance, msg.Price.Obj will throw an IncorrectDataFormat exception, because the engine will not convert "" to float (or DateTime, or int, etc.). You can use msg.GetString(44).Length to get the field as a string and query its length.
Y
N
Y
ValidateUserDefinedFields If set to N, user-defined fields will not be rejected if they are not defined in the data dictionary, or are not present in messages they do not belong to.
Y
N
Y
AllowUnknownMsgFields If set to Y, non user-defined fields (field with tag < 5000) will not be rejected if they are not defined in the data dictionary, or are present in messages they do not belong to.
(Only applies to fields outside repeating groups; fields in groups must still obey the configured data dictionary or be rejected.)
Y
N
N
CheckLatency If Y, messages must be received from the counterparty within a defined number of seconds (see MaxLatency). It is useful to turn this off if a system uses localtime for its timestamps instead of GMT.
Y
N
Y
MaxLatency If CheckLatency=Y, this defines the number of seconds latency allowed for a message to be processed.
positive integer
120

Initiator

Setting Description Valid Values Default
ReconnectInterval Time between reconnection attempts in seconds. Only used for initiators. NOTE: must be defined in DEFAULT section Positive integer 30
HeartBtInt Heartbeat interval in seconds. Only used for initiators. Positive integer -
LogonTimeout Number of seconds to wait for a logon response before disconnecting. Positive integer 10
LogoutTimeout Number of seconds to wait for a logout response before disconnecting. Positive integer 2
SocketConnectPort Socket port for connecting to a session. Only used for initiators. Positive integer -
SocketConnectHost Host to connect to. Only used for initiators. Valid IP address in the format of x.x.x.x or a domain name -
SocketConnectPort<n> Alternate socket ports for connecting to a session for failover, where n is a positive integer. ie, SocketConnectPort1, SocketConnectPort2... must be consecutive and have a matching SocketConnectHost<n> Positive integer -
SocketConnectHost<n> Alternate socket hosts for connecting to a session for failover, where n is a positive integer. ie, SocketConnectHost1, SocketConnectHost2... must be consecutive and have a matching SocketConnectPort<n> Valid IP address in the format of x.x.x.x or a domain name -

Acceptor

Setting Description Valid Values Default
SocketAcceptPort Socket port for listening to incoming connections. Only used with acceptors. Positive integer, valid open socket port -
SocketAcceptHost Socket host for listening to incoming connections. If not provided, the acceptor will listen on all network interfaces (0.0.0.0) Valid IP address in the format of x.x.x.x 0.0.0.0

Socket Configuration

SocketNodelay Disable Nagle's algorithm for this connection. Written data to the network is not buffered pending acknowledgement of previously written data. Currently, this must be defined in the [DEFAULT] section.
Y
N
Y
SocketSendBufferSize Set the size (in bytes) of the TCP send buffer.
(See related .NET API)
integer
8192
SocketReceiveBufferSize Set the size (in bytes) of the TCP receive buffer
(See related .NET API)
integer
8192
SocketSendTimeout Set the time that the TCP socket will wait for a send operation to complete successfully
(See related .NET API)
integer
0
SocketReceiveTimeout Set the time that the TCP socket will wait for a receive operation to complete successfully
(See related .NET API)
integer
0

Storage

Setting Description Valid Values Default
PersistMessages If set to N, no messages will be persisted. This will force QuickFIX to always send GapFills instead of resending messages. Use this if you know you never want to resend a message. Useful for market data streams.
Y
N
Y

File Storage

Setting Description Valid Values Default
FileStorePath Directory to store sequence number and message files. Valid directory for storing files, must have write access. -

Logging

Setting Description Valid Values Default
FileLogPath Directory to store logs. Valid directory for storing files, must have write access -
DebugFileLogPath Directory to store ThreadedClientAcceptor thread logs. Valid directory for storing files, must have write access Value of FileLogPath if present, else "log".

SSL

Setting Description Valid Values Default
SSLEnable Determine if SSL should be used.
Y
N
Y if SSLCertificatePath is specified, otherwise N
SSLServerName The expected certificate name of the server (usually same as DNS name). Only used for initiators. string defaults to value of SocketConnectHost
SSLProtocols Specifies the SSLProtocol to use (according to the C# SslProtocols enum). If .NET 4.5 is used there are more valid values. Refer to this MSDN page for a complete list of valid values.
Ssl2
Ssl3
Tls
Default
Any other valid SslProtocols enum value
Default
SSLValidateCertificates If Y, the remote party's certificate will be verified against the certificate specified by the SSLCACertificate setting (or the operating system's list of trusted CAs if that setting is not specified).
NOTE: setting the value to N is a security risk.
Setting the value to N will also set SSLCheckCertificateRevocation to N.
Y
N
Y
SSLCheckCertificateRevocation Determine if certificate revocation list (CRL) should be used to check if SSL certificates have been revoked. Will be overridden to N if SSLValidateCertificates=N.
Y
N
Y
SSLCertificate Specifies which SSL certificate (containing a private key) to use. Required for acceptor, but not for initiator unless client certificates are used. The certificate can be loaded either from a pfx file or from the current user's personal certificate store.
  • Path to a .pfx-file to which read access is granted
  • Distinguished name (ex: CN=CertName) of a certificate in the current user's personal certificate store
  • Subject name (ex: CertName) of a certificate in the current user's personal certificate store
-
SSLCertificatePassword Password for the SSL certificate string -
SSLRequireClientCertificate Determine if acceptor should require client certificates from all acceptors
Y
N
Y
SSLCACertificate Specifies the CA certificate used by acceptor to validate client certificates. If not specified, then all certificates installed on the computer's certificate store (under "Trusted Root Certificates") are used. The certificate can be loaded either from a file or from the current user's personal certificate store.
  • Path to a .cer- or .pfx-file to which read access is granted
  • Distinguished name (ex: CN=CertName) of a certificate in the current user's personal certificate store
  • Subject name (ex: CertName) of a certificate in the current user's personal certificate store
-

Sample Initiator Settings File

Here is a typical initiator settings file you might find in a firm that wants to connect to several ECNs.

# default settings for sessions
[DEFAULT]
FileStorePath=store
FileLogPath=log
ConnectionType=initiator
ReconnectInterval=60
SenderCompID=TW

# session definition
[SESSION]
# inherit FileStorePath, FileLogPath, ConnectionType, 
#    ReconnectInterval and SenderCompID from default
BeginString=FIX.4.1
TargetCompID=ARCA
StartTime=12:30:00
EndTime=23:30:00
HeartBtInt=20
SocketConnectPort=9823
SocketConnectHost=123.123.123.123
DataDictionary=somewhere/FIX41.xml

[SESSION]
BeginString=FIX.4.0
TargetCompID=ISLD
StartTime=12:00:00
EndTime=23:00:00
HeartBtInt=30
SocketConnectPort=8323
SocketConnectHost=23.23.23.23
DataDictionary=somewhere/FIX40.xml

[SESSION]
BeginString=FIX.4.2
TargetCompID=INCA
StartTime=12:30:00
EndTime=21:30:00
# overide default setting for RecconnectInterval
ReconnectInterval=30
HeartBtInt=30
SocketConnectPort=6523
SocketConnectHost=3.3.3.3
# (optional) alternate connection ports 
#  and hosts to cycle through on failover
SocketConnectPort1=8392
SocketConnectHost1=8.8.8.8
SocketConnectPort2=2932
SocketConnectHost2=12.12.12.12
DataDictionary=somewhere/FIX42.xml

Sample Acceptor Settings File

Here is a typical acceptor settings file.

# default settings for sessions
[DEFAULT]
FileStorePath=store
FileLogPath=log
ConnectionType=acceptor
ReconnectInterval=60
SenderCompID=ARCA

# session definition
[SESSION]
# inherit FileStorePath, FileLogPath, ConnectionType, 
#  ReconnectInterval and SenderCompID from default
BeginString=FIX.4.1
TargetCompID=TW
StartTime=12:30:00
EndTime=23:30:00
HeartBtInt=20
SocketAcceptPort=9823
DataDictionary=somewhere/FIX41.xml

[SESSION]
BeginString=FIX.4.0
TargetCompID=TW
StartTime=12:00:00
EndTime=23:00:00
HeartBtInt=30
SocketAcceptPort=8323
DataDictionary=somewhere/FIX40.xml

[SESSION]
BeginString=FIX.4.2
TargetCompID=TW
StartTime=12:30:00
EndTime=21:30:00
# overide default setting for RecconnectInterval
ReconnectInterval=30
HeartBtInt=30
SocketAcceptPort=6523
# (optional) only listen for incoming connections on a specific host
SocketAcceptHost=127.0.0.1
DataDictionary=somewhere/FIX42.xml

Example Applications

We’ve made three QuickFIX/N example applications:


The Simple Acceptor is a barebones acceptor that prints any message it receives to the console.


The Trade Client is a command-line client that sends order messages.


The Executor listens for order messages and responds with mock execution responses.


The Trade Client and Executor can be configured to send and execute orders with each other.


Have your own app you’d like to share? Contact us!

Custom Fields, Groups,
and Messages

We often connect to parties who have modified or customized the FIX protocol to fit their needs. QuickFIX/N provides us some powerful ways to deal with this problem, the easiest of which is through the Data Dictionary.

Data Dictionary

A Data Dictionary documents the protocol for a QuickFIX/N Session. When a field, group, or message is custom for a session versus the FIX specification, we change this document.


We specify data dictionary for a session in the config file:

[Session]
SenderCompID=CONNAMARA
TargetCompID=CBOE
BeginString=FIX4.2
UseDataDictionary=Y
DataDictionary=./spec/FIX4.2.xml

The XML-based document is fairly straightforoward.


A Data Dictionary defines all FIX Fields:

<fields>
  <field number="1" name="Account" type="STRING"/>
  <field number="2" name="AdvId" type="STRING"/>
  <field number="3" name="AdvRefID" type="STRING"/>
...

A Data Dictionary defines all FIX Messages:

<messages>
  <message name="Heartbeat" msgtype="0" msgcat="admin">
    <field name="TestReqID" required="N"/>
  </message>
  <message name="Logon" msgtype="A" msgcat="admin">
    <field name="EncryptMethod" required="Y"/>
    <field name="HeartBtInt" required="Y"/>
...

And a Data Dictionary defines all FIX within a Message:


<message name="Logon" msgtype="A" msgcat="admin">
  <field name="EncryptMethod" required="Y"/>
  <field name="HeartBtInt" required="Y"/>
  <field name="RawDataLength" required="N"/>
  <field name="RawData" required="N"/>
  <field name="ResetSeqNumFlag" required="N"/>
  <field name="MaxMessageSize" required="N"/>
  <group name="NoMsgTypes" required="N">
    <field name="RefMsgType" required="N"/>
    <field name="MsgDirection" required="N"/>
  </group>
</message>

Customizing Our Data Dictionary

Adding custom fields to existing messages

Many counterparties’ customizations are limited to only adding custom fields to existing FIX messages.


Create the field:


If your counterparty is adding a already-existing field to a message that doesn’t normally use it, then your field should already be defined, and you can skip this step.


If the counterparty has created this field, then you must define it. Here, we’ll add a new string field called AwesomeField as tag 9006.


Note: your new field must have a name and tag unique from all other fields in your Data Dictionary.


To do this, we would go to the fields section of the Data Dictionary, and add a new field entry for the new AwesomeField field.


<fields>
  <field number="1" name="Account" type="STRING"/>
  <field number="2" name="AdvId" type="STRING"/>
  <field number="3" name="AdvRefID" type="STRING"/>
...
  <field number="9006" name="AwesomeField" type="STRING"/>
</fields>

That’s it! Your field can now be used in other messages.


Add the field to a message:


If the field is not being added in a repeating group, then your altered message will look like this:


<message name="ExecutionReport" msgtype="8" msgcat="app">
  <field name="OrderID" required="Y"/>
  <field name="SecondaryOrderID" required="N"/>
  <field name="ClOrdID" required="N"/>
  <field name="OrigClOrdID" required="N"/>
  <field name="TestReqID" required="N"/>
...
  <field name="AwesomeField" required="N"/>
</message>

If the field is being added to a repeating group, then you must add it inside the appropriate group tag. In the following excerpt, we add it to the NoContraBrokers group.


  • Note 1: If your group is not specified correctly, your message will be rejected or interpreted incorrectly.
  • Note 2: For FIX 4.0-4.4, the order of fields inside a repeating group is important. Make sure the position of your field matches that of the actual message to be received, or your message will be rejected.

<message name="ExecutionReport" msgtype="8" msgcat="app">
  <field name="OrderID" required="Y"/>
...
  <field name="ExecBroker" required="N"/>
  <group name="NoContraBrokers" required="N">
    <field name="ContraBroker" required="N"/>
    <field name="ContraTrader" required="N"/>
    <field name="ContraTradeQty" required="N"/>
    <field name="ContraTradeTime" required="N"/>
    <field name="AwesomeField" required="N"/>
  </group>
...

Adding new messages types

Some counterparies add entirely new message types to FIX.


To add a new message type to the Data Dictionary, there are two steps:


  1. Add a new message definition to the messages section.
  2. Add a new corresponding entry to the MsgType field within the fields section

For example, here is how you’d add a new message type called CoolMessage that contains 3 fields (1 of which is required, the others mandatory):


Note: The msgtype and name (both are strings) must be unique from all other messages.


<messages>
  ...
  <message name="CoolMessage" msgcat="app" msgtype="xCM">
    <field name="Currency" required="N"/>
    <field name="Text" required="N"/>
    <field name="Account" required="Y"/>
  </message>
  ...
</messages>
...
<fields>
  ...
  <field number='35' name='MsgType' type='STRING'>
    ...
    <value enum='xCM' description='COOLMESSAGE'/>
  </field>
  ...
</fields>

Adding new groups

Groups are a little more nuanced than other parts of the Data Dictionary.


A group is defined within a message, with the group tag. The first child element of the group tag is the group-counter tag, followed by the other fields in the group in the order in which they should appear in the message.


Don’t forget to define the group counter field in the fields section! By convention, the field usually starts with “No”, e.g. if the group is called “NeatGroup”, the counter field would be called “NoNeatGroups” (though this is not mandatory).


  • Note 1: If your group is not specified correctly, your message will be rejected or interpreted incorrectly.
  • Note 2: For FIX 4.0-4.4, the order of fields inside a repeating group is important. Make sure the position of your field matches that of the actual message to be received, or your message will be rejected.

Here is how you would add a new group ‘BrandNewGroup’ to the message ‘CoolMessage’ that created in the previous section:


<messages>
  ...
  <message name="CoolMessage" msgcat="app" msgtype="CM">
    <field name="Currency" required="N"/>
    <field name="Text" required="N"/>
    <field name="Account" required="Y"/>
    <group name="NoBrandNewGroups" required="N">
      <field name="ExecID" required="Y"/>
      <field name="OrderID" required="N"/>
      <!-- ... maybe other fields ... -->
    </group>
  </message>
  ...
</messages>
...
<fields>
  ...
  <field number='9876' name='NoBrandNewGroups' type='NUMINGROUP'/>
</fields>

In Code

The easiest way to get a custom field from a message or group is to call the typed getter:


const int AWESOME_FIELD = 9006;
string awsmFld = message.GetString(AWESOME_FIELD);
const int AWESOME_FIELD = 9006;
string awsmFld = contraBrokersGrp.GetString(AWESOME_FIELD);

For setting a custom field, we use one of the generic Field type classes:


const int AWESOME_FIELD = 9006;
message.SetField(new StringField(AWESOME_FIELD, "ohai"));
const int AWESOME_FIELD = 9006;
contraBrokersGrp.SetField(new StringField(AWESOME_FIELD, "ohai"));

QuickFIX .NET Wrapper Compatibility

QuickFIX/n is not compatible with the QuickFIX C++ .NET wrapper. This means you cannot simply replace the .NET wrapper DLLs with the QuickFIX/n DLL, and expect your existing code to compile.


The QuickFIX programming style is unchanged, so the top level interfaces you wrote code against are still the same. Creating an application is still the same as before. Your application needs to implement the standard application callbacks (FromApp, ToApp, etc…). MessageCracker is still the recommended way to receive messages, and you write your code in the OnMessage callbacks. Sending a message to a counterparty is the same method call.


Most of the changes you need to make to an existing application are minor, such as changing a method or namespace name. Below is a list of known compatibility issues:


  • Method names are now upper camel case.


    For example: Session.logout() is now Session.Logout() and Application.fromApp() is now Application.FromApp()


  • Getter and setter methods no longer exist and have been (or will eventually be) replaced with .NET properties.


    Previously, you would call order.getClOrdID() to get the ClOrdID value from a NewOrderSingle message. Now, just use order.ClOrdID


    For a setter: exec.setField(order.getClOrdID()); is now exec.ClOrdID = order.ClOrdID;


  • Interface classes now start with I, per .NET convention. For instance, where you’d implement an Application in QuickFIX/C++, you’ll now implement an IApplication.


  • FIX Message classes used to be part of the QuickFix## namespace, where ## is the FIX version. Now they are part of the QuickFix.FIX## namespace.


    For example: QuickFix42.NewOrderSingle is now QuickFix.FIX42.NewOrderSingle


  • Socket acceptor and initiator classes are different.


    QuickFIX/n’s default initiator is QuickFix.Transport.SocketInitiator and the default acceptor is QuickFix.ThreadedSocketAcceptor


  • There may be new or different QuickFIX settings. Please look at the configuration page to determine if you need to update your configuration files.


If we missed anything, let us know