Imported from previous forum
The Nordic Growth Markets have submitted a proposal to allow the initiator to reset the MsgSeqNum in the Logon message (not only as part of 24-hour connectivity). Additionally the proposal also includes extensions for some error codes to convey that the session state is corrupt and a reset is required to restart the session.
The GTC co-chairs are soliciting feedback from the user community on this extension proposal.
Please post any comments to this thread. Please submit all feedback by Friday, June 4th.
A link to the proposal can be found at:
http://www.fixprotocol.org/documents/5164/NGM%20Logon%20Extension%20v02.pdf
The Nordic Growth Markets have submitted a proposal to allow the
initiator to reset the MsgSeqNum in the Logon message (not only as part
of 24-hour connectivity). Additionally the proposal also includes
extensions for some error codes to convey that the session state is
corrupt and a reset is required to restart the session.The GTC co-chairs are soliciting feedback from the user community on
this extension proposal.Please post any comments to this thread. Please submit all feedback by
Friday, June 4th.A link to the proposal can be found at: http://www.fixprotocol.org/docu-
ments/5164/NGM%20Logon%20Extension%20v02.pdf
This would potentially create enormous redevelopment costs for FIX compliant systems. Their implementations are predicated upon this sort of thing not being possible.
Further, it will be a bad thing to allow the remote party to force a reset the session during an active business cycle. Other than the “…only keeps a message history of X messages” the scenarios are bugs which should be fixed rather than worked around this way. Only keeping X messages seems to be a fundamental departure from the protocol.
I am not in favour of this proposal.
Page 6 / 9 of this proposal states
Initiator’s MsgSeqNum is too low. The acceptor expected a higher MsgSeqNum, i.e. the session state is corrupt.
I agree the Session state is corrupt but this solution is not correct and contradicts the FIX specs in multiple ways.
- In FIX specs FIX.4.0++ & FIXT.1.1 I find
If the incoming message has a sequence number less than expected and the PossDupFlag is not set, it indicates a serious error. It is strongly recommended that the session be terminated and manual intervention be initiated.
- Sending a Logon without a Logout will fall under the category of second connection attempt while a valid FIX session is already underway
[Start Quote from FIXT.1.1 Page 37 / 66]
When to send a Logout vs. when to just disconnect
If during a Logon one receives a second connection attempt while a valid FIX session is already underway for that same SenderCompID, it is recommended that the session acceptor immediately terminate the second connection attempt and not send a Logout message. Sending a Logout message runs the risk of interfering with and possibly adversely affecting the current active FIX connection. For example, in some FIX system implementations, sending a Logout message might consume a sequence number that would cause an out of sequence condition for the established FIX session.
[End Quote]
If any party has “X FIX messages limitation”, then let them “gracefully” logout and reinitiate a new Logon starting with SeqNum = 1 and ResetSeqNumFlag=Y. This way they do not have to deal with a larger message queue than X messages, this is as per present FIX specs. Since Business objects at the counterparty’s trading application would stay alive based on other criteria, for example : An Order with TIF=GTC stays alive thru multiple logouts and logons, an order with TIF=DAY would stay alive thru multiple logouts and logons thru the day.
FIX Engine Session behaviours would have to be turned upside down to accommodate this propasal.
Regards,
K. Mahesh
The Nordic Growth Markets have submitted a proposal to allow the
initiator to reset the MsgSeqNum in the Logon message (not only as
part of 24-hour connectivity). Additionally the proposal also includes
extensions for some error codes to convey that the session state is
corrupt and a reset is required to restart the session.The GTC co-chairs are soliciting feedback from the user community on
this extension proposal.Please post any comments to this thread. Please submit all feedback by
Friday, June 4th.A link to the proposal can be found at: http://www.fixprotocol.org/docu-
ments/5164/NGM%20Logon%20Extension%20v02.pdfThis would potentially create enormous redevelopment costs for FIX
compliant systems. Their implementations are predicated upon this sort
of thing not being possible.Further, it will be a bad thing to allow the remote party to force a
reset the session during an active business cycle. Other than the
“…only keeps a message history of X messages” the scenarios are bugs
which should be fixed rather than worked around this way. Only keeping X
messages seems to be a fundamental departure from the protocol.I am not in favour of this proposal.
Nordic Growth Markets (NGM) Logon Extension Proposal is requesting changes to allow the initiator to reset the MsgSeqNum in the Logon message (not only as part of 24-hour connectivity).
Contradiction with
[Start Quote from FIX specs]
SESSION PROTOCOL
It is recommended that a new FIX session be established once within each 24 hour period. It is possible to maintain 24 hour connectivity and establish a new set of sequence numbers by sending a Logon message with the ResetSeqNumFlag set.
When using the ResetSeqNumFlag to maintain 24 hour connectivity and establish a new set of sequence numbers, the process should be as follows. “Both sides should agree on a reset time and the party that will be the initiator of the process. Note that the initiator of the ResetSeqNum process may be different than the initiator of the Logon process.” One side will initiate the process by sending a TestRequest and wait for a Heartbeat in response to ensure of no sequence number gaps. Once the Heartbeat has been received, 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. 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.
[End Quote]
NGM’s Logon reset MsgSeqNum to 1 using ResetSeqNumFlag = Y can occur anytime, present FIX Logon reset happens only at prefixed bilaterally agreed uopn time.
[ original email was from Mikael Brannstrom - mikael.brannstrom@ngm.se ]
Hi Mahesh,
Revision 0.4 of the logon extension contains proposed changes to the FIXT 1.1 documentation. It seems that revision 0.2 is the one that is posted.
See my answers below.
- If the incoming message has a sequence number less than expected and the PossDupFlag is not set, it indicates a serious error. It is strongly recommended that the session be terminated and manual intervention be initiated.
As of today, manual intervention is the only way. The proposal is to have automatic recovery as an option, which would work as follows: terminate the connection and Logon again with ResetSeqNumFlag=Y. After a Logon with reset it is recommended that snapshots are requested for any state that need to be in sync between the parties, e.g. Order Mass Status Request for orders, and so on.
- Sending a Logon without a Logout will fall under the category of second connection attempt while a valid FIX session is already underway
I cannot see how the proposal contradicts this. The Logon with ResetSeqNumFlag=Y is never sent while logged in, it is only sent when initiating a new FIX connection.
In that sense it is the 24-hour-connectivity Logon with reset that is odd, since it is sent when already logged in.
Since Business objects at the counterparty’s trading application would stay alive based on other criteria, for example : An Order with TIF=GTC stays alive thru multiple logouts and logons, an order with TIF=DAY would stay alive thru multiple logouts and logons thru the day.
FIX Engine Session behaviours would have to be turned upside down to accommodate this propasal.
Business level objects can always be recovered by requesting snapshots, e.g. Order Mass Status Request, Trade Capture Report Request, Market Data Request, Security List Request etc. You only need to remember if you reset, in which case snapshots are needed as well.
In the proposed documentation changes in revision 0.4, it says that it is recommended to request snapshots whenever logon with reset has been made.
I also pulled in you comment from http://fixprotocol.org/discuss/read/519fd8a9:
NGM’s Logon reset MsgSeqNum to 1 using ResetSeqNumFlag = Y can occur anytime, present FIX Logon reset happens only at prefixed bilaterally agreed uopn time.
The “NGM Logon reset” can only occur at Logon when initiating a FIX connection. It is just like a normal Logon but with the ResetSeqNumFlag=Y.
I hope my answers straightened things out.
Regards
Mikael Brännström, NGM
[ original email was from Mikael Brannstrom - mikael.brannstrom@ngm.se ]
> Further, it will be a bad thing to allow the remote party to force a reset the session during an active business cycle. Other than the “…only keeps a message history of X messages” the scenarios are bugs which should be fixed rather than worked around this way.
For the record, not only (software) bugs can cause the FIX session state to become corrupt. A server may fail for a number of reasons. Even if you have site failover and X number of hot standby servers, all these might fail.
This proposal is about how to recover from a failure if it happens, instead of saying that errors never happen.
Further, it will be a bad thing to allow the remote party to force a reset the session during an active business cycle. Other than the “…only keeps a message history of X messages” the scenarios are bugs which should be fixed rather than worked around this way.
For the record, not only (software) bugs can cause the FIX session state to become corrupt. A server may fail for a number of reasons. Even if you have site failover and X number of hot standby servers, all these might fail.
This proposal is about how to recover from a failure if it happens, instead of saying that errors never happen.
Kindly see this link for my reply. http://fixprotocol.org/discuss/read/b7a67693
[ original email was from Mikael Brannstrom - mikael.brannstrom@ngm.se ]
Hi Dennis,
Could you please clarify your previous statement?
This would potentially create enormous redevelopment costs for FIX compliant systems. Their implementations are predicated upon this sort of thing not being possible.
Logon with ResetSeqNumFlag=Y is the same as
- Logon with MsgSeqNum=MAX_INTEGER, NextExpectedMsgSeqNum=1, followed by
- SeqReset-Reset, NewSeqNo=1
… but without starting the message retransmission as a consequence of step 1.
Steps 1 and 2 are allowed today. In what way would merging these two steps into one step “create enormous redevelopment costs for FIX compliant systems”?
Regards
Mikael Brännström
Hi Dennis,
Could you please clarify your previous statement?
This would potentially create enormous redevelopment costs for FIX compliant systems. Their implementations are predicated upon this sort of thing not being possible.
Logon with ResetSeqNumFlag=Y is the same as
- Logon with MsgSeqNum=MAX_INTEGER, NextExpectedMsgSeqNum=1, followed by
- SeqReset-Reset, NewSeqNo=1
… but without starting the message retransmission as a consequence of step 1.Steps 1 and 2 are allowed today. In what way would merging these two steps into one step “create enormous redevelopment costs for FIX compliant systems”?
Regards
Mikael Brännström
Hi Mikael,
I apologise for having to stand against this proposal. In response to your queries…
If memory serves, it is not allowed to seqeuence-reset-reset to a number lower than what is next expected. You are only allowed to reset higher. Any session approaching MAX_INT messages over one session likely more urgently needs to split up the traffic over multiple sessions.
As regards your previous question re: costs to redevelop and test existing systems. Much of the session state and logic is predicated upon existing data having been committed and applied to the receiving system’s state. Sequence numbers never go lower and the session rules guard against that allowing deeper code to safely assume that predicate. Further, the message logs document the contracted commitments of the two parties on either side of the connection allowing for issue resolution.
So existing systems would potentially need to be redeveloped, retested and recertified if/when new clients claim that our FIX implementation does not conform to the FIX standard.
We have experienced clients & vendors demanding we support this behavior after having seen the 24 hour reset seq num “feature” in the FIX specification. This led to many headaches which too often were abused by vendors and clients, creating potential liabilities for our company. The vast majority of the time connecting parties simply wanted to avoid fixing their bugs or avoid putting into place the required hardware.
Ultimately, I would not have any concerns with this proposal if our experiences would have been more positive. Instead, we had nothing but bad experiences with remote connecting vendors and clients using the reset seq num feature as an “out” which then required us to work around their irresponsibility. Where does our liability and responsibility end?
It seems that the more appropriate approach to the scenarios this proposal covers is for the session initiator to accept that the bug or hardware failure occured on its side and, rather than demanding that the session acceptor reset sequence numbers lower, the session initiator should increase its sequence numbers and notify operators that investigation is required. The session acceptor can include the “next expected seq num” in the logout which rejects the logon. In the case of “the system only stores X messages” then the retrans request should be gap filled up to the point at which the X messages can be resent. Overall, I believe that this is what the FIX protocol presently recommends and such a solution does not impact existing implementations.
Dennis,
thank you for the feedback which raises an important issue. Apparently, a well intended feature to reset sequence numbers has been mis-used by parts of the FIX community and caused numerous issues for firms like yours. This could very well be caused by ambiguities in the spec that people take advantage of. It could also be an initial lack of understanding and then (after development) looking for something else to blame to avoid the cost of dveloping it as intended by FIX.
I therefore see the removal of ambiguities as an alternative to the rejection of extensions to features that are being mis-used today. Clear and official usage guidelines from FPL should help discussions with vendors over such issues.
I suggest to focus on the use cases for a reset of sequence numbers, including the ones currently allowed by FIX and the NGM requirements. I hope we can find a way to support all of them without offering loopholes to lazy developers. I see a need to do something regardless of NGM’s proposal due to the bad experiences you made in the past.
It might mean that we have to extend NGM’s proposal to fix existing ambiguities as well. The alternative for NGM in case of a simple rejection of their proposal is to go away and use custom tags. This cannot be in the interest of FPL and I believe we need to put in more effort to solve NGM’s business requirements. The current proposal might not be the only way to achieve this but then we need to show another way within the boundaries of the current spec (or with a different kind of extension).
Regards,
Hanno.
Hi Mikael,
I apologise for having to stand against this proposal. In response to your queries…
If memory serves, it is not allowed to seqeuence-reset-reset to a number lower than what is next expected. You are only allowed to reset higher. Any session approaching MAX_INT messages over one session likely more urgently needs to split up the traffic over multiple sessions.
As regards your previous question re: costs to redevelop and test existing systems. Much of the session state and logic is predicated upon existing data having been committed and applied to the receiving system’s state. Sequence numbers never go lower and the session rules guard against that allowing deeper code to safely assume that predicate. Further, the message logs document the contracted commitments of the two parties on either side of the connection allowing for issue resolution.
So existing systems would potentially need to be redeveloped, retested and recertified if/when new clients claim that our FIX implementation does not conform to the FIX standard.
We have experienced clients & vendors demanding we support this behavior after having seen the 24 hour reset seq num “feature” in the FIX specification. This led to many headaches which too often were abused by vendors and clients, creating potential liabilities for our company. The vast majority of the time connecting parties simply wanted to avoid fixing their bugs or avoid putting into place the required hardware.
Ultimately, I would not have any concerns with this proposal if our experiences would have been more positive. Instead, we had nothing but bad experiences with remote connecting vendors and clients using the reset seq num feature as an “out” which then required us to work around their irresponsibility. Where does our liability and responsibility end?
It seems that the more appropriate approach to the scenarios this proposal covers is for the session initiator to accept that the bug or hardware failure occured on its side and, rather than demanding that the session acceptor reset sequence numbers lower, the session initiator should increase its sequence numbers and notify operators that investigation is required. The session acceptor can include the “next expected seq num” in the logout which rejects the logon. In the case of “the system only stores X messages” then the retrans request should be gap filled up to the point at which the X messages can be resent. Overall, I believe that this is what the FIX protocol presently recommends and such a solution does not impact existing implementations.
Hello Hanno,
“The alternative for NGM in case of a simple rejection of their proposal is to go away and use custom tags.”
Respectfully, I must disagree.
As noted below, the sessions can resume communications if the session initiator receives the “next expected seq num” in the logout sent by the session acceptor when it receives the logon with seq num less than expected. The session initiator then sends a logon on with seq num set to the value which was sent by the session acceptor.
Thus, communications are resumed and the session initiator (the one who had the programmatical or hardware error) is the one who makes the correction.
As far as I can tell, this achieves the goals of NGM’s proposal though via different means. Contrast this to what is proposed.
If the session acceptor is the one who must change when instructed by the session initiator, then they have to either reset their message database or modify their database design to accomodate how messages are indexed.
If the database is reset, then how does one resolve issues reported later in the day or days later? Have a second copy of the database and move the messages over? If the messages are simply deleted, we are propogating the failure (loss of messages) from the session initiator’s system to the session acceptor’s system.
What if there are multiple resets during the day? Must the session acceptor be capable of retaining an unlimited number of sets of session messages?
If multiple sets of messages are stored in the message database, how is the session acceptor supposed to identify which messages are from before and after the logon with reset when a restrans request is received?
If the session acceptor subsequently has a failure and restarts after the session initiator has invoked one or more resets, how is the session acceptor to determine which set of messages it should use to determine what the starting sequence numbers should be?
With multiple sets of messages, how much more complex will problem investigation and resolution become? How much will the complexity of certification increase?
I acknowledge that all of these challenges can be solved by efforts (costs) on the session acceptor’s side. Thus, the proposal by NGM forces all these changes on the side of the session acceptor when the issues the proposal attempts to address are entirely on the side of the session initiator.
Yet the solution I suggest is far simpler for both sides of the FIX session and puts the onus upon the system which had the failure. Is this not the way it should be? “System heal thyself”? ;o)
Thanks for all your replies and the stimulating discussion. This is the last I will comment on this topic. My opinion remains unchanged - I oppose this proposal and hope it does not become part of the standard.
Best regards,
Dennis
Dennis,
thank you for the feedback which raises an important issue. Apparently, a well intended feature to reset sequence numbers has been mis-used by parts of the FIX community and caused numerous issues for firms like yours. This could very well be caused by ambiguities in the spec that people take advantage of. It could also be an initial lack of understanding and then (after development) looking for something else to blame to avoid the cost of dveloping it as intended by FIX.
I therefore see the removal of ambiguities as an alternative to the rejection of extensions to features that are being mis-used today. Clear and official usage guidelines from FPL should help discussions with vendors over such issues.
I suggest to focus on the use cases for a reset of sequence numbers, including the ones currently allowed by FIX and the NGM requirements. I hope we can find a way to support all of them without offering loopholes to lazy developers. I see a need to do something regardless of NGM’s proposal due to the bad experiences you made in the past.
It might mean that we have to extend NGM’s proposal to fix existing ambiguities as well. The alternative for NGM in case of a simple rejection of their proposal is to go away and use custom tags. This cannot be in the interest of FPL and I believe we need to put in more effort to solve NGM’s business requirements. The current proposal might not be the only way to achieve this but then we need to show another way within the boundaries of the current spec (or with a different kind of extension).
Regards,
Hanno.Hi Mikael,
I apologise for having to stand against this proposal. In response to your queries…
If memory serves, it is not allowed to seqeuence-reset-reset to a number lower than what is next expected. You are only allowed to reset higher. Any session approaching MAX_INT messages over one session likely more urgently needs to split up the traffic over multiple sessions.
As regards your previous question re: costs to redevelop and test existing systems. Much of the session state and logic is predicated upon existing data having been committed and applied to the receiving system’s state. Sequence numbers never go lower and the session rules guard against that allowing deeper code to safely assume that predicate. Further, the message logs document the contracted commitments of the two parties on either side of the connection allowing for issue resolution.
So existing systems would potentially need to be redeveloped, retested and recertified if/when new clients claim that our FIX implementation does not conform to the FIX standard.
We have experienced clients & vendors demanding we support this behavior after having seen the 24 hour reset seq num “feature” in the FIX specification. This led to many headaches which too often were abused by vendors and clients, creating potential liabilities for our company. The vast majority of the time connecting parties simply wanted to avoid fixing their bugs or avoid putting into place the required hardware.
Ultimately, I would not have any concerns with this proposal if our experiences would have been more positive. Instead, we had nothing but bad experiences with remote connecting vendors and clients using the reset seq num feature as an “out” which then required us to work around their irresponsibility. Where does our liability and responsibility end?
It seems that the more appropriate approach to the scenarios this proposal covers is for the session initiator to accept that the bug or hardware failure occured on its side and, rather than demanding that the session acceptor reset sequence numbers lower, the session initiator should increase its sequence numbers and notify operators that investigation is required. The session acceptor can include the “next expected seq num” in the logout which rejects the logon. In the case of “the system only stores X messages” then the retrans request should be gap filled up to the point at which the X messages can be resent. Overall, I believe that this is what the FIX protocol presently recommends and such a solution does not impact existing implementations.
That is good news because it means that NGM can achieve their objective by means of existing FIX capabilities and usage guidelines. That is the better solution but it requires NGM to recognize it. You have provided ample feedback for NGM which will hopefully help to achieve this.
My point was that somebody who comes forward with a proposal that is rejected without offering an alternative will not be tempted to think hard about such an alternative but will often take the easy route of custom tags. I was not saying that there is no other alternative for NGM but only that others need to come forward to point to alternatives which is what you have done.
The discussion will continue in tomorrow’s Global Exchanges and Markets Committee and I hope that we can make some progress for NGM in this matter.
Hello Hanno,
“The alternative for NGM in case of a simple rejection of their proposal is to go away and use custom tags.”
Respectfully, I must disagree.
As noted below, the sessions can resume communications if the session initiator receives the “next expected seq num” in the logout sent by the session acceptor when it receives the logon with seq num less than expected. The session initiator then sends a logon on with seq num set to the value which was sent by the session acceptor.
Thus, communications are resumed and the session initiator (the one who had the programmatical or hardware error) is the one who makes the correction.
As far as I can tell, this achieves the goals of NGM’s proposal though via different means. Contrast this to what is proposed.
If the session acceptor is the one who must change when instructed by the session initiator, then they have to either reset their message database or modify their database design to accomodate how messages are indexed.
If the database is reset, then how does one resolve issues reported later in the day or days later? Have a second copy of the database and move the messages over? If the messages are simply deleted, we are propogating the failure (loss of messages) from the session initiator’s system to the session acceptor’s system.
What if there are multiple resets during the day? Must the session acceptor be capable of retaining an unlimited number of sets of session messages?
If multiple sets of messages are stored in the message database, how is the session acceptor supposed to identify which messages are from before and after the logon with reset when a restrans request is received?
If the session acceptor subsequently has a failure and restarts after the session initiator has invoked one or more resets, how is the session acceptor to determine which set of messages it should use to determine what the starting sequence numbers should be?
With multiple sets of messages, how much more complex will problem investigation and resolution become? How much will the complexity of certification increase?
I acknowledge that all of these challenges can be solved by efforts (costs) on the session acceptor’s side. Thus, the proposal by NGM forces all these changes on the side of the session acceptor when the issues the proposal attempts to address are entirely on the side of the session initiator.
Yet the solution I suggest is far simpler for both sides of the FIX session and puts the onus upon the system which had the failure. Is this not the way it should be? “System heal thyself”? ;o)
Thanks for all your replies and the stimulating discussion. This is the last I will comment on this topic. My opinion remains unchanged - I oppose this proposal and hope it does not become part of the standard.
Best regards,
Dennis
[ original email was from Mikael Brannstrom - mikael.brannstrom@ngm.se ]
Hi Dennis,
Thanks for your more detailed comments.
Would the following be a better solution?
-
“the system only stores X messages” is responded with a GapFill with a new field, e.g. MsgHistoryLostIndicator=Y/N (default=N), that tells the other side that it probably need to request snapshots since some important messages could not be retransmitted.
We will probably have to come up with a better name for the new field to capture other usages. For example, it might be a bad idea to resend several GB of data intraday - instead a snapshot would be a quicker way to recover. -
“It seems that the more appropriate […] include the ‘next expected seq num’ in the logout”. Good point. This approach does not rule out the reset on logon feature. Both will work in parallel.
-
Reset on logon is an optional feature. Same as is “Logon Message NextExpectedMsgSeqNum Processing” and “24 hour logon reset” as it seems since it’s a bilateral agreement when and who initiates the 24 hour logon reset.
The “logon reset” is still usable for example if the client side did crash and quickly want to logon instead being forced to logon, receive a logout to see the NextExpectedSeqNum and then logon again. There are other use cases as well …
1, 2 and 3 together meet the requirements of NGM.
For future reference:
“If memory serves, it is not allowed to seqeuence-reset-reset to a number lower than what is next expected.”
You’re correct. This one was hard to find in the FIXT 1.1 spec. See test case with Ref ID 11c at page 46. Otherwise the spec is not that clear about this.
Regards
Mikael Brännström, NGM
Hi Mikael,
I apologise for having to stand against this proposal. In response to your queries…
If memory serves, it is not allowed to seqeuence-reset-reset to a number lower than what is next expected. You are only allowed to reset higher. Any session approaching MAX_INT messages over one session likely more urgently needs to split up the traffic over multiple sessions.
As regards your previous question re: costs to redevelop and test existing systems. Much of the session state and logic is predicated upon existing data having been committed and applied to the receiving system’s state. Sequence numbers never go lower and the session rules guard against that allowing deeper code to safely assume that predicate. Further, the message logs document the contracted commitments of the two parties on either side of the connection allowing for issue resolution.
So existing systems would potentially need to be redeveloped, retested and recertified if/when new clients claim that our FIX implementation does not conform to the FIX standard.
We have experienced clients & vendors demanding we support this behavior after having seen the 24 hour reset seq num “feature” in the FIX specification. This led to many headaches which too often were abused by vendors and clients, creating potential liabilities for our company. The vast majority of the time connecting parties simply wanted to avoid fixing their bugs or avoid putting into place the required hardware.
Ultimately, I would not have any concerns with this proposal if our experiences would have been more positive. Instead, we had nothing but bad experiences with remote connecting vendors and clients using the reset seq num feature as an “out” which then required us to work around their irresponsibility. Where does our liability and responsibility end?
It seems that the more appropriate approach to the scenarios this proposal covers is for the session initiator to accept that the bug or hardware failure occured on its side and, rather than demanding that the session acceptor reset sequence numbers lower, the session initiator should increase its sequence numbers and notify operators that investigation is required. The session acceptor can include the “next expected seq num” in the logout which rejects the logon. In the case of “the system only stores X messages” then the retrans request should be gap filled up to the point at which the X messages can be resent. Overall, I believe that this is what the FIX protocol presently recommends and such a solution does not impact existing implementations.
Hi Mikael,
“…with a new field, e.g. MsgHistoryLostIndicator=Y/N (default=N), that tells the other side that it probably need to request snapshots since some important messages could not be retransmitted.”
This is good. I’ve never encountered a system doing the “we only store X messages” yet it seems to me that the MsgHistoryLostIndicator will be a vital part of such functionality.
I submit to you, though, that if systems are requesting such large retransmissions there will be bigger hardware and software issues needing resolution. (How were there so many messages ‘in the pipe’ between the two systems unprocessed by the receiver? You suggest GB of messages. What communications medium supports such buffer sizes? If not in the transport layer, how can a receiving system with such insufficient performance get into production?)
Re: “bilateral agreement” - while this sounds good for making a proposal more acceptable, in practice it isn’t quite that simple. Vendors and clients can become entrenched (as I am) as to their positions. I.e. - one party demands the bilateral agreement while the other opposes it.
In our “bad experiences” the only thing that resolved the impass was the fact that we were not engaging in 24 hour connectivity. This proposal removes that obstacle.
Once again, best regards,
Dennis
Hi Dennis,
Thanks for your more detailed comments.
Would the following be a better solution?
“the system only stores X messages” is responded with a GapFill with a new field, e.g. MsgHistoryLostIndicator=Y/N (default=N), that tells the other side that it probably need to request snapshots since some important messages could not be retransmitted.
We will probably have to come up with a better name for the new field to capture other usages. For example, it might be a bad idea to resend several GB of data intraday - instead a snapshot would be a quicker way to recover.“It seems that the more appropriate […] include the ‘next expected seq num’ in the logout”. Good point. This approach does not rule out the reset on logon feature. Both will work in parallel.
Reset on logon is an optional feature. Same as is “Logon Message NextExpectedMsgSeqNum Processing” and “24 hour logon reset” as it seems since it’s a bilateral agreement when and who initiates the 24 hour logon reset.
The “logon reset” is still usable for example if the client side did crash and quickly want to logon instead being forced to logon, receive a logout to see the NextExpectedSeqNum and then logon again. There are other use cases as well …
1, 2 and 3 together meet the requirements of NGM.
For future reference:
“If memory serves, it is not allowed to seqeuence-reset-reset to a number lower than what is next expected.”
You’re correct. This one was hard to find in the FIXT 1.1 spec. See test case with Ref ID 11c at page 46. Otherwise the spec is not that clear about this.
Regards
Mikael Brännström, NGMHi Mikael,
I apologise for having to stand against this proposal. In response to your queries…
If memory serves, it is not allowed to seqeuence-reset-reset to a number lower than what is next expected. You are only allowed to reset higher. Any session approaching MAX_INT messages over one session likely more urgently needs to split up the traffic over multiple sessions.
As regards your previous question re: costs to redevelop and test existing systems. Much of the session state and logic is predicated upon existing data having been committed and applied to the receiving system’s state. Sequence numbers never go lower and the session rules guard against that allowing deeper code to safely assume that predicate. Further, the message logs document the contracted commitments of the two parties on either side of the connection allowing for issue resolution.
So existing systems would potentially need to be redeveloped, retested and recertified if/when new clients claim that our FIX implementation does not conform to the FIX standard.
We have experienced clients & vendors demanding we support this behavior after having seen the 24 hour reset seq num “feature” in the FIX specification. This led to many headaches which too often were abused by vendors and clients, creating potential liabilities for our company. The vast majority of the time connecting parties simply wanted to avoid fixing their bugs or avoid putting into place the required hardware.
Ultimately, I would not have any concerns with this proposal if our experiences would have been more positive. Instead, we had nothing but bad experiences with remote connecting vendors and clients using the reset seq num feature as an “out” which then required us to work around their irresponsibility. Where does our liability and responsibility end?
It seems that the more appropriate approach to the scenarios this proposal covers is for the session initiator to accept that the bug or hardware failure occured on its side and, rather than demanding that the session acceptor reset sequence numbers lower, the session initiator should increase its sequence numbers and notify operators that investigation is required. The session acceptor can include the “next expected seq num” in the logout which rejects the logon. In the case of “the system only stores X messages” then the retrans request should be gap filled up to the point at which the X messages can be resent. Overall, I believe that this is what the FIX protocol presently recommends and such a solution does not impact existing implementations.
[ original email was from Mikael Brannstrom - mikael.brannstrom@ngm.se ]
Hi Dennis,
The large retransmissions may occur on market data feeds. If a client gets disconnected for example one or few hours intraday and then reconnects, then that client have missed “GB of data” that need to be retransmitted. Instead a snapshot would be a better idea, since the client would get in sync much faster.
Regards
Mikael
Hi Mikael,
“…with a new field, e.g. MsgHistoryLostIndicator=Y/N (default=N), that tells the other side that it probably need to request snapshots since some important messages could not be retransmitted.”
This is good. I’ve never encountered a system doing the “we only store X messages” yet it seems to me that the MsgHistoryLostIndicator will be a vital part of such functionality.
I submit to you, though, that if systems are requesting such large retransmissions there will be bigger hardware and software issues needing resolution. (How were there so many messages ‘in the pipe’ between the two systems unprocessed by the receiver? You suggest GB of messages. What communications medium supports such buffer sizes? If not in the transport layer, how can a receiving system with such insufficient performance get into production?)
Re: “bilateral agreement” - while this sounds good for making a proposal more acceptable, in practice it isn’t quite that simple. Vendors and clients can become entrenched (as I am) as to their positions. I.e. - one party demands the bilateral agreement while the other opposes it.
In our “bad experiences” the only thing that resolved the impass was the fact that we were not engaging in 24 hour connectivity. This proposal removes that obstacle.
Once again, best regards,
Dennis
Hi Dennis,
Thanks for your more detailed comments.
Would the following be a better solution?
“the system only stores X messages” is responded with a GapFill with a new field, e.g. MsgHistoryLostIndicator=Y/N (default=N), that tells the other side that it probably need to request snapshots since some important messages could not be retransmitted.
We will probably have to come up with a better name for the new field to capture other usages. For example, it might be a bad idea to resend several GB of data intraday - instead a snapshot would be a quicker way to recover.“It seems that the more appropriate […] include the ‘next expected seq num’ in the logout”. Good point. This approach does not rule out the reset on logon feature. Both will work in parallel.
Reset on logon is an optional feature. Same as is “Logon Message NextExpectedMsgSeqNum Processing” and “24 hour logon reset” as it seems since it’s a bilateral agreement when and who initiates the 24 hour logon reset.
The “logon reset” is still usable for example if the client side did crash and quickly want to logon instead being forced to logon, receive a logout to see the NextExpectedSeqNum and then logon again. There are other use cases as well …
1, 2 and 3 together meet the requirements of NGM.
For future reference:
“If memory serves, it is not allowed to seqeuence-reset-reset to a number lower than what is next expected.”
You’re correct. This one was hard to find in the FIXT 1.1 spec. See test case with Ref ID 11c at page 46. Otherwise the spec is not that clear about this.
Regards
Mikael Brännström, NGMHi Mikael,
I apologise for having to stand against this proposal. In response to your queries…
If memory serves, it is not allowed to seqeuence-reset-reset to a number lower than what is next expected. You are only allowed to reset higher. Any session approaching MAX_INT messages over one session likely more urgently needs to split up the traffic over multiple sessions.
As regards your previous question re: costs to redevelop and test existing systems. Much of the session state and logic is predicated upon existing data having been committed and applied to the receiving system’s state. Sequence numbers never go lower and the session rules guard against that allowing deeper code to safely assume that predicate. Further, the message logs document the contracted commitments of the two parties on either side of the connection allowing for issue resolution.
So existing systems would potentially need to be redeveloped, retested and recertified if/when new clients claim that our FIX implementation does not conform to the FIX standard.
We have experienced clients & vendors demanding we support this behavior after having seen the 24 hour reset seq num “feature” in the FIX specification. This led to many headaches which too often were abused by vendors and clients, creating potential liabilities for our company. The vast majority of the time connecting parties simply wanted to avoid fixing their bugs or avoid putting into place the required hardware.
Ultimately, I would not have any concerns with this proposal if our experiences would have been more positive. Instead, we had nothing but bad experiences with remote connecting vendors and clients using the reset seq num feature as an “out” which then required us to work around their irresponsibility. Where does our liability and responsibility end?
It seems that the more appropriate approach to the scenarios this proposal covers is for the session initiator to accept that the bug or hardware failure occured on its side and, rather than demanding that the session acceptor reset sequence numbers lower, the session initiator should increase its sequence numbers and notify operators that investigation is required. The session acceptor can include the “next expected seq num” in the logout which rejects the logon. In the case of “the system only stores X messages” then the retrans request should be gap filled up to the point at which the X messages can be resent. Overall, I believe that this is what the FIX protocol presently recommends and such a solution does not impact existing implementations.
Hi Mikael,
Subscriptions for Market Data expire in such scenarios. When the session is re-established the subscription is made again by the subscriber requesting snapshot plus updates.
Please note, however, that some clients & vendors want to compile all market data for their internal systems usage. In such cases they will likely want to negotiate with NGM to be able to recover that information somehow.
We do this using a proprietary protocol rather than the FIX protocol.
Regards,
Dennis
Hi Dennis,
The large retransmissions may occur on market data feeds. If a client gets disconnected for example one or few hours intraday and then reconnects, then that client have missed “GB of data” that need to be retransmitted. Instead a snapshot would be a better idea, since the client would get in sync much faster.
Regards
MikaelHi Mikael,
“…with a new field, e.g. MsgHistoryLostIndicator=Y/N (default=N), that tells the other side that it probably need to request snapshots since some important messages could not be retransmitted.”
This is good. I’ve never encountered a system doing the “we only store X messages” yet it seems to me that the MsgHistoryLostIndicator will be a vital part of such functionality.
I submit to you, though, that if systems are requesting such large retransmissions there will be bigger hardware and software issues needing resolution. (How were there so many messages ‘in the pipe’ between the two systems unprocessed by the receiver? You suggest GB of messages. What communications medium supports such buffer sizes? If not in the transport layer, how can a receiving system with such insufficient performance get into production?)
Re: “bilateral agreement” - while this sounds good for making a proposal more acceptable, in practice it isn’t quite that simple. Vendors and clients can become entrenched (as I am) as to their positions. I.e. - one party demands the bilateral agreement while the other opposes it.
In our “bad experiences” the only thing that resolved the impass was the fact that we were not engaging in 24 hour connectivity. This proposal removes that obstacle.
Once again, best regards,
Dennis
Hi Dennis,
Thanks for your more detailed comments.
Would the following be a better solution?
“the system only stores X messages” is responded with a GapFill with a new field, e.g. MsgHistoryLostIndicator=Y/N (default=N), that tells the other side that it probably need to request snapshots since some important messages could not be retransmitted.
We will probably have to come up with a better name for the new field to capture other usages. For example, it might be a bad idea to resend several GB of data intraday - instead a snapshot would be a quicker way to recover.“It seems that the more appropriate […] include the ‘next expected seq num’ in the logout”. Good point. This approach does not rule out the reset on logon feature. Both will work in parallel.
Reset on logon is an optional feature. Same as is “Logon Message NextExpectedMsgSeqNum Processing” and “24 hour logon reset” as it seems since it’s a bilateral agreement when and who initiates the 24 hour logon reset.
The “logon reset” is still usable for example if the client side did crash and quickly want to logon instead being forced to logon, receive a logout to see the NextExpectedSeqNum and then logon again. There are other use cases as well …
1, 2 and 3 together meet the requirements of NGM.
For future reference:
“If memory serves, it is not allowed to seqeuence-reset-reset to a number lower than what is next expected.”
You’re correct. This one was hard to find in the FIXT 1.1 spec. See test case with Ref ID 11c at page 46. Otherwise the spec is not that clear about this.
Regards
Mikael Brännström, NGMHi Mikael,
I apologise for having to stand against this proposal. In response to your queries…
If memory serves, it is not allowed to seqeuence-reset-reset to a number lower than what is next expected. You are only allowed to reset higher. Any session approaching MAX_INT messages over one session likely more urgently needs to split up the traffic over multiple sessions.
As regards your previous question re: costs to redevelop and test existing systems. Much of the session state and logic is predicated upon existing data having been committed and applied to the receiving system’s state. Sequence numbers never go lower and the session rules guard against that allowing deeper code to safely assume that predicate. Further, the message logs document the contracted commitments of the two parties on either side of the connection allowing for issue resolution.
So existing systems would potentially need to be redeveloped, retested and recertified if/when new clients claim that our FIX implementation does not conform to the FIX standard.
We have experienced clients & vendors demanding we support this behavior after having seen the 24 hour reset seq num “feature” in the FIX specification. This led to many headaches which too often were abused by vendors and clients, creating potential liabilities for our company. The vast majority of the time connecting parties simply wanted to avoid fixing their bugs or avoid putting into place the required hardware.
Ultimately, I would not have any concerns with this proposal if our experiences would have been more positive. Instead, we had nothing but bad experiences with remote connecting vendors and clients using the reset seq num feature as an “out” which then required us to work around their irresponsibility. Where does our liability and responsibility end?
It seems that the more appropriate approach to the scenarios this proposal covers is for the session initiator to accept that the bug or hardware failure occured on its side and, rather than demanding that the session acceptor reset sequence numbers lower, the session initiator should increase its sequence numbers and notify operators that investigation is required. The session acceptor can include the “next expected seq num” in the logout which rejects the logon. In the case of “the system only stores X messages” then the retrans request should be gap filled up to the point at which the X messages can be resent. Overall, I believe that this is what the FIX protocol presently recommends and such a solution does not impact existing implementations.
Dear All,
A later version of this proposal is available via this link. We apologise to NGM for posting an older version for feedback.
http://www.fixprotocol.org/documents/5164/NGM%20Logon%20Extension%20v04.pdf
The Nordic Growth Markets have submitted a proposal to allow the initiator to reset the MsgSeqNum in the Logon message (not only as part of 24-hour connectivity). Additionally the proposal also includes extensions for some error codes to convey that the session state is corrupt and a reset is required to restart the session.
The GTC co-chairs are soliciting feedback from the user community on this extension proposal.
Please post any comments to this thread. Please submit all feedback by Friday, June 4th.
A link to the proposal can be found at:
http://www.fixprotocol.org/documents/5164/NGM%20Logon%20Extension%20v02.pdf