Amending an existing FIX connection to buffer requests.

, ,
1

Imported from previous forum

2

Many Thanks Christoph and Hanno - that sounds good to me.

3

If you use X as an intermediate between A and B, you should make use of header tags DeliverToCompID(128) and OnBehalfOfCompID(115) to reflect the fact that A and B are actually the ones communicating via FIX from a business perspective. From a technicqal perspective, you will have two FIX sessions (A-X and X-B) with their own sequencing and recovery. X can then decide to hold back when it knows B would not accept the messages and effectively queue them. A only sees a "delay" in responses, e.g. ExecutionReports not coming back immediately. X can send them with "pending XYZ" states to let A know that X has taken over responsibility.

4

OK, so you need to open two FIX sessions. One to A and one to B. Then of course you can disconnect the A side and let them buffer their requests and you can buffer the requests from B that should later be sent to A.

Cheers

5

Hi,

A -> B is the current FIX connection, but both sides maintained by third parties.

Our plan is to introduce another FIX process, X, in between.

A -> X -> B

The aim is that X will do the kind of buffering mentioned.  

A is the counterparty-ish and B is our order management system.

Thanks,

Chris

6

Hi,

are A and B both connected via FIX to X?

Until now I thought of A as some kind of OrderManagementSystem which is connecting internally to X (your FIX component) and B is your FIX counterparty.

This "queueing" in the message store only works for FIX of course.

 

Cheers

 

 

7

Hi Christoph,

Many thanks for your post.

I am planning to use QuickFIX/J - so that sounds good.

Just to clarify, if I add my new component (X) between A and B, then are you saying that if I disconnect X on the A side when I need to and let their side queue the requests until we are good to go?

I was planning to queue things internally, but that might be a better way to go - need to discuss with the A 'people' :)

Cheers,

Chris

8

Hi Chris,

 

IMHO you should be fine by simply disconnecting (or connecting at a later time) the connection and then write the requests to the outgoing message store. On the subsequent logon your sequence numbers will have increased which is recognized by the counterparty and they will request a resend of the missed messages.

I can only speak for QuickFIX/J but I guess that every FIX engine will support the feature of putting messages into the message store although the connection is down.

Cheers,

Christoph

9

Hi,

We have an existing FIX connection between 2 systems, lets says A and B (B is an acceptor, listens on a port, A is an initiator and connects to B).

For whatever environmental reasons B rejects messages a bit too eagerly, eg at start of day before the market is open.  What it should be doing is holding these until the market is open.  However B is provided by a third party and so we cannot change it quickly.

So, the plan is to put a new component in between the 2 - it will normally just pass the requests on, but when it detects the kind of situations that would lead to B rejecting the message, it will buffer them and wait until its a good time to send them.

Obviously I can write a custom component to do this, but I was wondering if there were any existing products that did this or if it was perhaps covered, maybe partially, by a FIX feature.  One thing that comes to mind is that messages are queued if the connection is not currently in place, so we could disconnect from B when the problem times occur and only reconnect when it should be good to do so.

Thanks in advance for any suggestions.

Cheers,

Chris