Imported from previous forum
[ original email was from Juergen Schwibs - Juergen.Schwibs@seb.se ]
We have the following problem with a customer Fix implementation:
On a change of a day we are resetting our SeqNum to 1 and force the client to relogin. Unfortenatly the client does not reset his SeqNum and login again using the sequence number from yesterday. We are answering the login message with a login message, change our internal sequence number counter and ask for resend of the message gap. Now the client recognize that is something wrong and logouts. After that the client resets his sequence number to 1 and login again.
Question is, if we have to accept the second login, because the resend of the messages were not accepted by the client in the way that he logged out or if we have to refuse the login, because the sequence number is lower than expected and PossDup is not set to Y.
//Jürgen
My response is assuming that there is a some period of agreed upon "down time" (could be 5 minutes) between "the end of one day" and "the new day" (vs. attempting to do this to an established session via the ResetSeqNumFlag).
Thus the core problem is that your counterparty neglected to properly reset their sequence numbers during the down time. This obviously is a pretty signficant problem which should be addressed with the counterparty.
If you find this situation occurring and need a suggestion for how to best "handle it" systematically, I would recommend:
IF you are expecting MsgSeqNum=1 from your counterparty AND
you receive a Logon with MsgSeqNum > MAX_SEQ_NUM_TOLERANCE_FOR_FIRST_LOGON
THEN terminate the session, do not increment inbound MsgSeqNum counter, and get humans involved
You might consider a moderately high number for MAX_SEQ_NUM_TOLERANCE_FOR_FIRST_LOGON such as 20% of a “normal” day’s worth of MsgSeqNum values.
I had to do something like this several years ago for a counterparty because they occassionally did not run their “end of day” process properly, (incorrectly) would accept my initiating Logon with MsgSeqNum of 1, would send me their Logon with a high MsgSeqNum, I would issue a ResendRequest, and they would send me the prior day’s Execution Reports which were dupes for me.
The bottom line is that properly resetting sequence numbers and performing end-of-day processing is very important.
> We have the following problem with a customer Fix implementation:
>
> On a change of a day we are resetting our SeqNum to 1 and force the client to relogin. Unfortenatly the client does not reset his SeqNum and login again using the sequence number from yesterday. We are answering the login message with a login message, change our internal sequence number counter and ask for resend of the message gap. Now the client recognize that is something wrong and logouts. After that the client resets his sequence number to 1 and login again.
>
> Question is, if we have to accept the second login, because the resend of the messages were not accepted by the client in the way that he logged out or if we have to refuse the login, because the sequence number is lower than expected and PossDup is not set to Y.
>
> //Jürgen
>
[ original email was from Akis Tzortzis - at@jesqa.com ]
How is the client side supposed to know which Logon is "new day" and which is "continuation" ?
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
Akis,
Scott suggests in the previous posting in this thread that the counterparties will agreed to a mutual start-of-day window during which time the session stays down or follows the plan laid out in the FIX spec for 24-hour connectivity. Once the server has setup the new day, the next logon from the client must be sequence 1. Subsequence logons continue the original session until the server once again rolls over to the next day.
> How is the client side supposed to know which Logon is "new day" and which is "continuation" ?
>
>
>