FIX messages and streaming

, ,
1

Imported from previous forum

2

Hi,

I’m fairly new to FIX, having come from a SWIFT-type background.

The most significant difference appears to be transport of the messages. Is there anyone who could describe how I would know in the TCP stream when it was ok to send a message?

This is particularly WRT opening a connection, logging in and opening streaming FX rates.

I’m expecting to continually receive new quote updates, and once they start flowing I’m not sure how to know when it’s ok to transmit something to the counter party.

Hope this all makes sense…

Regards,
Dave

3

[Quotes from FIX specs located at http://fixprotocol.org/specifications/]

A FIX session is defined as a bi-directional stream of ordered messages between two parties within a continuous sequence number series.

Logon -

Establishing a FIX connection involves three distinct operations: creation of a telecommunications level link, authentication/acceptance of the initiator by the acceptor and message synchronization (initialization).  The sequence of connection follows:

  • The session initiator establishes a telecommunication link with the session acceptor.

  • The initiator sends a Logon message. The acceptor will authenticate the identity of the initiator by examining the Logon message. The Logon message will contain the data necessary to support the authentication method previously agreed upon between the parties. If the initiator is successfully authenticated, the acceptor responds with a Logon message, if authentication fails, the session acceptor should shut down the connection. The session initiator may begin to send messages immediately following the Logon message, however, the session may not be supported by the other side at this time. The initiator must wait for the confirming Logon message from the acceptor before declaring the session fully established.
    After the initiator has been authenticated, the acceptor will respond immediately with a confirming Logon message. Depending on the encryption method being used for that session, this Logon message may or may not contain the same session encryption key. The initiator side will use the Logon message being returned from the acceptor as confirmation that a FIX session has been established. If the session acceptor has chosen to change the session encryption key, the session initiator must send a third Logon back to the other side in order to acknowledge the key change request. This also allows the session acceptor to know when the session initiator has started to encrypt using the new session key. Both parties are responsible for infinite loop detection and prevention during this phase of the session.

  • After authentication, the initiator and acceptor must synchronize their messages through interrogation of the MsgSeqNo field. A comparison of the MsgSeqNo in the Logon message to the internally monitored next expected sequence number will indicate any message gaps. Likewise, the initiator can detect gaps by comparing the acknowledgment Logon message MsgSeqNo to the next expected value. Refer to the section on message recovery later in this document for dealing with message gaps.

[End Quotes]

Hi,

I’m fairly new to FIX, having come from a SWIFT-type background.

The most significant difference appears to be transport of the messages.
Is there anyone who could describe how I would know in the TCP stream
when it was ok to send a message?

This is particularly WRT opening a connection, logging in and opening
streaming FX rates.

I’m expecting to continually receive new quote updates, and once they
start flowing I’m not sure how to know when it’s ok to transmit
something to the counter party.

Hope this all makes sense…

Regards, Dave

4

I think what I’m asking is:

Once I have a stream comming from the counter party do I have one thread constantly listening to the TCP socket and I use a another thread to write to it whilst the previous is still reading it.

IE: I’m not pausing reading to write. The 2 operations happen at the same time but are handled by different threads.

OR

Is is correct that I would pause reading, write my message in the hope my buffers don’t fill and then resume reading.

Dave

5

Yes you would have multiple Threads, one Socket reader Thread - reads the inbound data from TCP Socket, one Socket writer Thread - write outbound data to TCP Socket and many Worker Threads which would perform other business processes, displaying data to user(s), reacting to user events etc.

There is no need to pause reading to write or pause writing to read. Both inbound and outbound streams would be flowing at the same time.

I think what I’m asking is:

Once I have a stream comming from the counter party do I have one thread
constantly listening to the TCP socket and I use a another thread to
write to it whilst the previous is still reading it.

IE: I’m not pausing reading to write. The 2 operations happen at the
same time but are handled by different threads.

OR

Is is correct that I would pause reading, write my message in the hope
my buffers don’t fill and then resume reading.

Dave

6

Hi,

I’m fairly new to FIX, having come from a SWIFT-type background.

The most significant difference appears to be transport of the messages.
Is there anyone who could describe how I would know in the TCP stream
when it was ok to send a message?

Hi Dave,

I’d suggest that you take a look at the source code for one of the open source FIX engines, if you’d like to see some different approaches to managing FIX message traffic over TCP sockets.

Here are links to the major ones:

  1. QuickFix (C++ & Managed Wrappers)
    http://www.quickfixengine.org

  2. QuickFix/J (Java Implementation):
    http://www.quickfixj.org

  3. VersaFix (.NET/C# Implementation):
    VersaFix download | SourceForge.net

The complete source code for all of these different engines is available from their respective websites, and they serve as good examples of how to build your own FIX message processing code.

Cheers,

Russ