pooling FIX sessions

, ,
1

Imported from previous forum

2

Is it possible to ‘pool’ multiple FIX sessions. In other words, if an order was sent on session A, is it possible to cancel or amend it on session B?

3

[ original email was from Joseph Horowitz - joseph.horowitz@thomsonreuters.com ]
> Is it possible to ‘pool’ multiple FIX sessions. In other words, if an order was sent on session A, is it possible to cancel or amend it on session B?

Only if you don’t consider SenderCompID and SubID, etc. elements that make the order unique. In past specs. I believe it states that these fields are part of the order’s uniqueness.

However, here is a simple scheme that could work:

  1. clOrdID + SenderCompID must be unique across all FIX sessions from the same SenderCompID (sending firm)
  2. All sessions must include a SenderSubIDs too, to render each FIX session unique (and allow for DR / fail over)

Now you can send orders, cancels and replaces on any session you like, and you’ll only have to deal with possible race conditions (e.g. cancel received before the order) if you use this for true pooling of sessions. Of course you might only switch to another session should the session you sent the order on go down, and only live-pool the sessions for each new order only for optimal throughput across them (esp. for venues that limit the # of orders sent on a session).

4

Is it possible to ‘pool’ multiple FIX sessions. In other words, if an order was sent on session A, is it possible to cancel or amend it on session B?

Only if you don’t consider SenderCompID and SubID, etc. elements that make the order unique. In past specs. I believe it states that these fields are part of the order’s uniqueness.

However, here is a simple scheme that could work:

  1. clOrdID + SenderCompID must be unique across all FIX sessions from the same SenderCompID (sending firm)
  2. All sessions must include a SenderSubIDs too, to render each FIX session unique (and allow for DR / fail over)

Now you can send orders, cancels and replaces on any session you like, and you’ll only have to deal with possible race conditions (e.g. cancel received before the order) if you use this for true pooling of sessions. Of course you might only switch to another session should the session you sent the order on go down, and only live-pool the sessions for each new order only for optimal throughput across them (esp. for venues that limit the # of orders sent on a session).

Let me elaborate on what I am thinking of. Under normal failover setups, if one FIX engine goes down, another one is started and/or activated and takes over the sessions that the failed engine was handling. This works well except that it takes a while to re-establish the sessions.

The thought was to eliminate the engine start-up and session re-establishment delay by having two or more FIX engines running hot with each having equivalent sessions established and heartbeating with each counterparty (I used the term ‘pooled’ sessions). For the sake of simplicity, let’s assume that all activities go through engine A. If engine A goes down, engine B simply starts processing all the messages using its already active sessions. We can assume that all engines ‘share’ everything.

The issue I think I am having with this is that each order is ‘owned’ by the session it was sent on, and can not be amended by another session. In addition, any messages from the counterparty will always be returned on the same session as the order. If that session is down, nothing flows back until the downed session is reestablished.

Is this doable?

5

[ original email was from Joseph Horowitz - joseph.horowitz@thomsonreuters.com ]
> Let me elaborate on what I am thinking of. Under normal failover setups, if one FIX engine goes down, another one is started and/or activated and takes over the sessions that the failed engine was handling. This works well except that it takes a while to re-establish the sessions.

The thought was to eliminate the engine start-up and session re-establishment delay by having two or more FIX engines running hot with each having equivalent sessions established and heartbeating with each counterparty (I used the term ‘pooled’ sessions). For the sake of simplicity, let’s assume that all activities go through engine A. If engine A goes down, engine B simply starts processing all the messages using its already active sessions. We can assume that all engines ‘share’ everything.

The issue I think I am having with this is that each order is ‘owned’ by the session it was sent on, and can not be amended by another session. In addition, any messages from the counterparty will always be returned on the same session as the order. If that session is down, nothing flows back until the downed session is reestablished.

Is this doable?

Absolutely doable, as long as this isn’t true (as per the original suggestion I offered to decouple the message from the session): “each order is ‘owned’ by the session it was sent on, and can not be amended by another session”

  1. If the limitation is a function of your FIX engine, then you will need another (the one we wrote and use is not limited in this fashion).
  2. If this is a limitation in how you use your FIX engine, then change your usage. Since you only expect clients to send on one or the other then simply don’t use SenderCompID or session information to identify order requests. You won’t need to worry about race conditions, as clients won’t switch to the other live session unless the primary one goes down (that takes time to discover).
  3. If you are the server-side and concerned about message recovery (e.g. execution reports that were not delivered to your client) you can always send them to the backup FIX sessions (including earlier ones within a time-scale) should the primary disconnect. There is certainly some trickiness to this.

I suggest working with a software architect who understands FIX to help you with this development. However you may be in violation of the FIX spec., so please check ahead and decide if this is worth the possible headaches with counter-party FIX engines that can’t handle this workflow change.

6

Absolutely doable, as long as this isn’t true (as per the original suggestion I offered to decouple the message from the session): “each order is ‘owned’ by the session it was sent on, and can not be amended by another session”

  1. If the limitation is a function of your FIX engine, then you will need another (the one we wrote and use is not limited in this fashion).
  2. If this is a limitation in how you use your FIX engine, then change your usage. Since you only expect clients to send on one or the other then simply don’t use SenderCompID or session information to identify order requests. You won’t need to worry about race conditions, as clients won’t switch to the other live session unless the primary one goes down (that takes time to discover).
  3. If you are the server-side and concerned about message recovery (e.g. execution reports that were not delivered to your client) you can always send them to the backup FIX sessions (including earlier ones within a time-scale) should the primary disconnect. There is certainly some trickiness to this.

I suggest working with a software architect who understands FIX to help you with this development. However you may be in violation of the FIX spec., so please check ahead and decide if this is worth the possible headaches with counter-party FIX engines that can’t handle this workflow change.

Thanks for your help!

7

This is interesting. Can you please shed some light on how you are planning to ‘pool’ sessions.

Currently we have buy side parties connecting into us but have to use multiple connections mainly so that we can identify where an Order is coming from.

We have analyzed use of ‘Sub…ID’ tags but would want to see if there is another way.

Is it possible to ‘pool’ multiple FIX sessions. In other words, if an order was sent on session A, is it possible to cancel or amend it on session B?