Incrementing sequence numbers while the other side is logged out

, ,
1

Imported from previous forum

2

The scenario

A sends logon
B accepts logon
Everything cool, normal heartbeats
A sends an order
B accepts the order
Everything cool, normal heartbeats
A logs out
B confirms logout

B gets lot of fills while A is down, obviously it has to queue them.

Case 1

A sends logon with the seq number equal to whatever it was before log out
B replies with the seq number equal to whatever it was before log out
B sends all the fills that it had queued up.

Case 2

Basically, B starts queuing up the fills in the fix session

A sends logon with the seq number equal to whatever it was before log out
B replies with the seq number way higher than whatever it was before log out (it has incremented its outgoing seq number while A was logged out)
A is forced to send a resend request for those missing messages

My question is the following
Is it legal in FIX to increment the outgoing seq number while the other party is logged out? Shouldn’t they queue the messages in some place prior to the FIX session and not mess with the FIX seq numbers (Case 1)?

thanks

3

Hi,

I don’t think the errata specifies that the outgoing seqnum has to be incremented only when the message is sent out and not when the message is designated/meant to be sent out. Correct me in case I am wrong here. So legally both approaches are fine.But as a general rule, most engines increment the outgoing seqnum when the message is actually sent out and fills when the connection is down is queued up internally without incrementing the outgoing seqnum.

Case 2 also helps in the maintainance point of view in identifying the messages actually sent to A and messages/fills yet to be sent to A by using the outgoing seqnum.

Hope this helps.

Cheers,
James

4

Thanks for your response. I wish the documentation were a bit clearer about this. My feeling is it should be wrong to increment the outgoing sequence number when you haven’t even attempted to send the message even once. If I log out cleanly, I expect to be able to log back in with the same sequence number. Is there any way to get official clarification about this?

thanks

Hi,

I don’t think the errata specifies that the outgoing seqnum has to be incremented only when the message is sent out and not when the message is designated/meant to be sent out. Correct me in case I am wrong here. So legally both approaches are fine.But as a general rule, most engines increment the outgoing seqnum when the message is actually sent out and fills when the connection is down is queued up internally without incrementing the outgoing seqnum.

Case 2 also helps in the maintainance point of view in identifying the messages actually sent to A and messages/fills yet to be sent to A by using the outgoing seqnum.

Hope this helps.

Cheers,
James

5

Hi Sandeep,

the case 2 sounds a bit more understandable if you consider this:

A message arrives from the business layer at the FIX engine. The first step is to save the message in the local file store. At this time it is tagged with the current time and sequence number. If the session is currently logged on, the message is immediately sent.

Otherwise, some times later the session is logged on and the Logon message has higher sequence number because it comes later in time.
Now the other side issues a ResendRequest, the message is fetched from
the local store, the OrigSendingTime is filled from the recorded timestamp and the SendingTime is filled from the current time.
In this way, the counter party can see that the message is sent quite a while ago and could reject it (e.g. stale order).

Do you see the benefit of this scenario?

Cheers, Jörg

Thanks for your response. I wish the documentation were a bit clearer about this. My feeling is it should be wrong to increment the outgoing sequence number when you haven’t even attempted to send the message even once. If I log out cleanly, I expect to be able to log back in with the same sequence number. Is there any way to get official clarification about this?

thanks

Hi,

I don’t think the errata specifies that the outgoing seqnum has to be incremented only when the message is sent out and not when the message is designated/meant to be sent out. Correct me in case I am wrong here. So legally both approaches are fine.But as a general rule, most engines increment the outgoing seqnum when the message is actually sent out and fills when the connection is down is queued up internally without incrementing the outgoing seqnum.

Case 2 also helps in the maintainance point of view in identifying the messages actually sent to A and messages/fills yet to be sent to A by using the outgoing seqnum.

Hope this helps.

Cheers,
James

6

I agree, case 2 seems reasonable and I guess it is easier to implement too rather than queuing messages prior to FIX layer. But I am just curious as to what’s the official word on this. Is it ok to increment the outgoing sq numbers when the other side is logged out and you haven’t even attempted to send the message at least once? I can’t find anything in the spec which says if it is OK or not OK to do this.

thanks

7

At least the open source QuickFIX and QuickFIX/J engines do it this way.
Maybe some commercial engine vendors may also comment. With regard to
the spec it may be left open by design.

I agree, case 2 seems reasonable and I guess it is easier to implement too rather than queuing messages prior to FIX layer. But I am just curious as to what’s the official word on this. Is it ok to increment the outgoing sq numbers when the other side is logged out and you haven’t even attempted to send the message at least once? I can’t find anything in the spec which says if it is OK or not OK to do this.

8

Hi,

The Minerva OMS and Cameron engine implements case 1. The if the counterparty is logged out, the business layer (Minerva) will queue the messages without incrementing the outgoing seq num until a logon is established. It then sends the messages that was queued to the counterparty.

Regards,
Quan

At least the open source QuickFIX and QuickFIX/J engines do it this way.
Maybe some commercial engine vendors may also comment. With regard to
the spec it may be left open by design.

I agree, case 2 seems reasonable and I guess it is easier to implement too rather than queuing messages prior to FIX layer. But I am just curious as to what’s the official word on this. Is it ok to increment the outgoing sq numbers when the other side is logged out and you haven’t even attempted to send the message at least once? I can’t find anything in the spec which says if it is OK or not OK to do this.