Imported from previous forum
Hi.
We are currently experiencing the following problem:
It seems that if there is a steady amount of data being transmitted from the acceptor, it does not accept any inbound messages, therefore not processing the heartbeat message in response to it test request, causing acceptor to disconnect the session because it hasn’t processed the message within the 30 second interval.
In other words, how does FIX handle heavy load? It seems that if we increase heartbeat interval, this will fix the problem, but heartbeat then becomes useless.
Another way to fix this problem is to add special messages indicating startup retransmission.
What is the correct approach?
Thank you.
Dmitry
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
Heartbeats are only needed during times of inactivity. One should only send a Test Request if one hasn’t received either a Heartbeat OR another valid message within HeartBtInt + some transmission delay.
If your trading partner is flooding you with messages so fast that there’s a significant delay (relative to HeartBtInt) between when the other party sends the message and when you processed it, you should never detect inactivity, never should even see a Heartbeat, and never send a Test Request.
> It seems that if there is a steady amount of data being transmitted from the acceptor, it does not accept any inbound messages, therefore not processing the heartbeat message in response to it test request, causing acceptor to disconnect the session because it hasn’t processed the message within the 30 second interval.
>
> In other words, how does FIX handle heavy load? It seems that if we increase heartbeat interval, this will fix the problem, but heartbeat then becomes useless.
>
> Another way to fix this problem is to add special messages indicating startup retransmission.
> What is the correct approach?
The case I am describing is the following:
One side (initiator) will start sending a great number of messages, let’s say 80,000. They will all go through, but there might be processing delay on the other side, such that after initiator is done sending messages and the 30 second delay has passed, acceptor is still busy processing this great load. So when initiator will send a heartbeat, acceptor will not be able to reply to it just yet, which will result in forced disconnect.
Please tell me what you think of this case?
The TCP socket communication is asynchronous, thus one should be able to both send and read messages. The “acceptor” in your case should still be servicing it’s requirements for outbound communication during the 30 seconds of processing inbound messages fast-and-furiously so I would expect the acceptor to still send a Heartbeat message on its interval.
> The case I am describing is the following:
>
> One side (initiator) will start sending a great number of messages, let’s say 80,000. They will all go through, but there might be processing delay on the other side, such that after initiator is done sending messages and the 30 second delay has passed, acceptor is still busy processing this great load. So when initiator will send a heartbeat, acceptor will not be able to reply to it just yet, which will result in forced disconnect.
>
> Please tell me what you think of this case?
>
Even though your Fix engine is under a heavy load of incoming messages it should still be sending a heartbeat every 30 seconds so a forced disconnect should not happen.
> The case I am describing is the following:
>
> One side (initiator) will start sending a great number of messages, let’s say 80,000. They will all go through, but there might be processing delay on the other side, such that after initiator is done sending messages and the 30 second delay has passed, acceptor is still busy processing this great load. So when initiator will send a heartbeat, acceptor will not be able to reply to it just yet, which will result in forced disconnect.
>
> Please tell me what you think of this case?
>