Sequence Number Question

, ,
1

Imported from previous forum

2

Hello All,

I am recently developing a FIX client and encountered two problems
regarding handling incoming messages with a sequence number gap.

  1. If the sequence number of the incoming test request is bigger than
    expected, according to the spec, I should not process the message
    (i.e. respond with a heart beat), but instead should handle the gap
    first. One way to handle the gap is to discard the out-of-sequence
    test message and send a resend request asking for all messages from
    the beginning of the gap.

However, the spec also says that test messages should never be
retransmitted. The end result is that the incoming test message is
never processed-- the first time because it is out of sequence; and
the second time it was not retransmitted, and the server might think
that the client is dead as it will never receive a heart beat in
response to the (out-of-sequence) test request.

  1. This problem is similar to the above one. After a connection is
    established, the client send a log-on message to the server and the
    server responds with a log-on confirmation. However, if the log-on
    confirmation is out of sequence, the client should not process it, but
    should send out a resend-request instead. As log-on messages are not
    allowed to be retransmitted, the log-on confirmation will never be
    included in messages the server resends. So the log-on confirmation is
    essentially lost. The client is never fully logged on!

I am sure that I misunderstand the spec somehow. If anyone knows of
the correct way of handling such scenarios, please let me know.

Thanks,
Geoffrey

3

[ original email was from John Prewett - jprewett@lavatrading.com ]
1. A good question.
TestRequest is typically only sent when a heartbeat is missing or immediately after logon.

When sending a TestRequest due to missing heartbeat(s), the objective is a warning: “If you don’t respond to this in a timely manner, I will disconnect you”. In the out-of-sequence TestRequest case, receiving a ResendRequest (or indeed any message) should prove that the FIX session is still alive to the sender of the TestRequest, thus a Heartbeat response to the (not retransmitted) TestRequest shouldn’t be required.

Some FIX engines send a TestRequest immediately after Logon, so that they don’t start to send application messages until any potential resequencing is completed. If both the Logon & TestRequest are out-of-sequence (high), a ResendRequest will be received instead of a Heartbeat response. The engine can assume that application sending can commence immediately after it has finished processing the ResendRequest. Again, no response to the TestRequest will be received as it will not be retransmitted.

  1. A Logon message must be processed even if it is out-of-sequence. In your example, a Logon response should be sent, immediately followed by a ResendRequest.

I hope this helps.

4

Hi John,

Many thanks for your reply. I think that they make a lot of sense.

One thing that concerns me a little is that the FIX spec does not seem to say much about these behaviors for test requests and log on confirmation.

It does seem to define what the server should do if it receives an out-of-sequence log on from the client, but does not seem to say much about the client receiving an out-of-sequence log on confirmation.

It doesn’t mention the subtlties of test request at all.

Geoffrey

> 1. A good question.
> TestRequest is typically only sent when a heartbeat is missing or immediately after logon.
>
> When sending a TestRequest due to missing heartbeat(s), the objective is a warning: “If you don’t respond to this in a timely manner, I will disconnect you”. In the out-of-sequence TestRequest case, receiving a ResendRequest (or indeed any message) should prove that the FIX session is still alive to the sender of the TestRequest, thus a Heartbeat response to the (not retransmitted) TestRequest shouldn’t be required.
>
> Some FIX engines send a TestRequest immediately after Logon, so that they don’t start to send application messages until any potential resequencing is completed. If both the Logon & TestRequest are out-of-sequence (high), a ResendRequest will be received instead of a Heartbeat response. The engine can assume that application sending can commence immediately after it has finished processing the ResendRequest. Again, no response to the TestRequest will be received as it will not be retransmitted.
>
> 2. A Logon message must be processed even if it is out-of-sequence. In your example, a Logon response should be sent, immediately followed by a ResendRequest.
>
> I hope this helps.
>

5

RE: "One thing that concerns me a little is that the FIX spec does not seem to say much about these behaviors for test requests and log on confirmation."

This is documented in the FIX Protocol Spec’s Volume 2’s “FIX Sesion-level Test Cases and Expected Behaviors”, specifically the “FIX Logon Process State Transition Diagram”.

This same section can be found in the standalone document: http://www.fixprotocol.org/ORGANIZATIONS/928202077/FIX_TestCase_SessionLevel20010710.doc

> Hi John,
>
> Many thanks for your reply. I think that they make a lot of sense.
>
> One thing that concerns me a little is that the FIX spec does not seem to say much about these behaviors for test requests and log on confirmation.
>
> It does seem to define what the server should do if it receives an out-of-sequence log on from the client, but does not seem to say much about the client receiving an out-of-sequence log on confirmation.
>
> It doesn’t mention the subtlties of test request at all.
>
> Geoffrey
>
>
> > 1. A good question.
> > TestRequest is typically only sent when a heartbeat is missing or immediately after logon.
> >
> > When sending a TestRequest due to missing heartbeat(s), the objective is a warning: “If you don’t respond to this in a timely manner, I will disconnect you”. In the out-of-sequence TestRequest case, receiving a ResendRequest (or indeed any message) should prove that the FIX session is still alive to the sender of the TestRequest, thus a Heartbeat response to the (not retransmitted) TestRequest shouldn’t be required.
> >
> > Some FIX engines send a TestRequest immediately after Logon, so that they don’t start to send application messages until any potential resequencing is completed. If both the Logon & TestRequest are out-of-sequence (high), a ResendRequest will be received instead of a Heartbeat response. The engine can assume that application sending can commence immediately after it has finished processing the ResendRequest. Again, no response to the TestRequest will be received as it will not be retransmitted.
> >
> > 2. A Logon message must be processed even if it is out-of-sequence. In your example, a Logon response should be sent, immediately followed by a ResendRequest.
> >
> > I hope this helps.
> >
>