Is there a requirement/good practice on how the client and server message flow should work in FIX?

1

Hi,

Is there a requirement on how the message flow will work between the FIX engines? As an example:

  1. A broker FIX engine connects to a MTF FIX engine and sends a Logon request.
  2. Broker can send in NewOrderSingles and in return get a ExecutionReport as a response from the MTF.

(This might not make sense but just want to illustrate)
Technically we could change step 1 to be “MTF connects to the broker and sends a Logon” and keep step 2?

As long as you have a defined FIX specification with a message flow anyone could act as “server”?

/ John

2

Please have a look at the FIX session protocol specification (FIX Transport (FIXT) – FIX Trading Community v2.1). Both engines have to “login” to each other. FIX only distinguishes between a session initiator and a session acceptor. FIX does not define who the initiator of a session has to be. That is left to bilateral agreement. In the case of an MTF or other execution venue and its customers, it is typically the customer of that venue who has to initiate the session.

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 previously agreed upon authentication method. If the initiator is successfully authenticated, the acceptor responds with a Logon message. If authentication fails, the session acceptor should shut down the connectionafter optionally sending a Logout message to indicate the reason of failure. Sending a Logout in this case is not required because doing so would consume a sequence number for that session, which in some cases may be problematic. The session initiator may begin to send messages immediately following the Logon message, however, the acceptor may not be ready to receive them. The initiator must wait for the confirming Logon message from the acceptor before declaring the session fully established.