FIX Trading Community

 

 Remember me

Register  |   Lost password?

General Q/A

Discussions > General Q/A > MsgSeqNum Question about the Logon Message

MsgSeqNum Question about the Logon Message

Complete message thread from old site

FIX Trading Community
13 January 2003 4:19am

[ original email was from Terence Tang - cptang_terence@yahoo.com ]
From the FIX specification
"the initiator should send a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. The acceptor should respond with a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. At this point new messages from either side should continue with MsgSeqNum of 2"

If the connection breaks before the initiator gets the logon message from the acceptor.
Should the initiator re-send the logon message ResetSeqNumFlag = Y and MsgSeqNum = 1, and what is the acceptors behavior if the acceptor has already processed the login message.
Or should the initiator re-send the logon message ResetSeqNumFlag = Y and MsgSeqNum = 2.

Thanks

Terence

Scott Atwell
13 January 2003 12:06pm

I'll answer your question in two ways. The first assuming "normal" Logon starting from a disconnected state. The second will attempt to address the trickier/more complicated ResetSeqNum=Y for a connected session.

Normal:
-------
If you've sent the message then you've consumed that MsgSeqNum. You shouldn't "guess" or "assume" that they've received it. In the example you cited, the initiator's next Logon would use MsgSeqNum=2 and the acceptor would either: a) have already received MsgSeqNum=1 and expect 2 thus accept and continue or b) expect MsgSeqNum=1 and accept and issue a ResendRequest with BeginSeqNo=1 for which the initiator would send a Sequence Reset - Gap Fill.
-- see "FIX Session-level Test Cases and Expected Behaviors" in Volume 2 of FIX 4.3 or within "FPL Organization", "Global Technical Committee", "Archive".

ResetSeqNum=Y for a connected session:
--------------------------------------
This is more complex. Note that the subsequent sentences from the spec in the paragraph you cited state: "It should be noted that once the initiator sends the Logon with the ResetSeqNumFlag set, the acceptor must obey this request and the message with the last sequence number transmitted “yesterday” may no longer be available. The connection should be shutdown and manual intervention taken if this process is initiated but not followed properly." I would consider the scenario you idetnified as "not followed properly" and thus "the connection should be shutdown and manual intervention taken".

One problem with simply attempting to establish a new connection (after the failure and connection shutdown) with either MsgSeqNum of 1 or 2 is that the acceptor might still have messages it intended to send to you which it was not able to transmit during the "properly" handled ResetSeqNum processing. There are obviously other issues and challenges.

> From the FIX specification
> "the initiator should send a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. The acceptor should respond with a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. At this point new messages from either side should continue with MsgSeqNum of 2"
>
> If the connection breaks before the initiator gets the logon message from the acceptor.
> Should the initiator re-send the logon message ResetSeqNumFlag = Y and MsgSeqNum = 1, and what is the acceptors behavior if the acceptor has already processed the login message.
> Or should the initiator re-send the logon message ResetSeqNumFlag = Y and MsgSeqNum = 2.
>
>
> Thanks
>
> Terence
>

Prakash Kannan
14 January 2003 2:03am

Considering only the scenario when ResetSeqNum=Y

If the connection breaks before the initiator receives a logon message back from the acceptor, the initiator has no way of knowing if the acceptor has received its logon message with ResetSeqNum=Y so it cannot increment its sequence number.

so logically the initiator should always send logon message with MsgSeqNum = 1 and ResetSeqNum=Y till it receives a logon message back from the acceptor.

The acceptor incase it has already received the logon message with ResetSeqNum=Y. it should not effect because the acceptor can again reset its sequence number.

Bruce Mahfood
15 January 2003 10:10pm

I am actually still working in 4.0, and we have never seen a reason to implement any restriction on the size of a message, but we recently got a request to start handling list order messages, and that is where I ran into the comment that instigated this question.

I take it from what you write that even with 4.0 there shouldn't be a problem with length, but rather that the issue is more one of how big is an int on the machines that will have to deal with the message, and since int is currently larger on more current machines than when this restriction was written, they should be able to handle this pretty easily. Is this correct?

Scott Atwell
15 January 2003 11:54pm

Bruce, I think you meant to post this response in the "Max Message Size" vs. "MsgSeqNum Question about the Logon Message" Discussion thread.

I think one could legitimately interpret the spec as stating that they can't accept a message with BodyLength > 9999 because that's what the spec prior to 4.2 says. I think you should bilaterally discuss and agree to this with your counterparties.

It's not as simple as the machine-specific size of an "int". There are likely some practical, finite limits for implementations. I would encourage them to be > 9999, though....

> I am actually still working in 4.0, and we have never seen a reason to implement any restriction on the size of a message, but we recently got a request to start handling list order messages, and that is where I ran into the comment that instigated this question.
>
> I take it from what you write that even with 4.0 there shouldn't be a problem with length, but rather that the issue is more one of how big is an int on the machines that will have to deal with the message, and since int is currently larger on more current machines than when this restriction was written, they should be able to handle this pretty easily. Is this correct?
>
>