Problem initialising a Fix Connection

, ,
1

Imported from previous forum

2

[ original email was from John Prewett - jprewett@lavatrading.com ]
Congratulations for breaking the record on the longest post to fixprotocol.org :wink:

I have looked at the first few messages and have some comments :

  1. The FIX session initiator (not you) sends an initial Logon message with ResetSeqNumFlag(141)=Y.
    It seems to me to be unclear from the specification as to whether this is "approved" usage of this field or not. This field is documented explicitly for maintaining 24 hour connectivity when a logon is sent over an already established session in order to effectively reset the sequence numbers without disconnecting. Having experienced many problems with non-24 hour connectivity whereby one end of a session forgot to (manually) reset the sequence numbers overnight, it would be helpful to use the ResetSeqNumFlag on an initial Logon message when you really were expecting the sequence numbers to have been reset anyway. I notice that CME requires this behavior.
    Either way, the acceptor (you) sends a reject to the logon request as it deems ResetSeqNumFlag=Y on an initial Logon message to be invalid and then it disconnects. This behavior could easily be considered reasonable.
  2. The initiator tries to Logon again. This time the Logon is now sent with MsgSeqNum=2 and ResetSeqNumFlag=N. The acceptor is OK with this and sends a logon in response. The acceptor also sends a ResendRequest message to request the resending of ONLY MsgSeqNum=1 because it didn’t store the previously received “invalid” Logon message. This isn’t perfect as maybe it should have stored the previously received Logon message, given the fact that it chose to respond to it, but it isn’t catastrophic.
  3. The initiator responds to the ResendRequest, in my humble opinion, with a slightly poor response. It sent a SequenceReset-gap fill message with MsgSeqNum=1, NewSeqNo=3. Why did it not have NewSeqNo=2 given the fact that you only asked for a resend of [1,1]?
  4. The acceptor (you) then over-reacts to the resending of MsgSeqNum=1, in my humble opinion. As your FIX engine is using the "resend requests to explicitly fill a gap" system rather than the more recommended "resend requests thru infinity" method, it should be prepared to receive a SequenceReset-gap fill message that spans beyond the range it requests. It should just treat that as completely filling the gap and be done with it.

Summary:

Both initiator and acceptor are misbehaving.

The actual breakdown in the early part of the log is due to the acceptor (you) when processing a SequenceReset-gap fill message that more-than-fills the gap that you requested to be filled with a ResendRequest message.

I didn’t have the time to look any further in your log than that.

I hope this helps.

[Over to you Ryan & Scott to correct my mistakes :wink: ]

3

[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
John’s assessments are on track. Here’s my reading:

Remote errors include:

  1. [Logon 141=Y] is only needed in a non-24-hour connection. But this should not be fatal.
  2. Response to [ResendRequest 1-1] should be [GapFill 1-2] not [GapFill 1-3]. But this again should not be fatal.
  3. We don’t see heartbeats here, but the interval is 60 seconds and the fatal error occurs 60 seconds after the “Sequence reset” log. Judging from the logs the [invisible] heartbeat at 6:31:07 was sent with sequence 3 but should have been sent with 5.

Local errors include:

  1. Denial of a Logon should be Logout, not Reject. Including 141=Y is not a session-level rule violation and could be interpreted as confirmation that requestor is at start-of-day.
  2. Receiving [GapFill 1-3] should not reset your next-expected sequence number. You have messages 2, 3 and 4 in hand and you didn’t ask to have them resent. Also the ERROR alarm seems to imply that the GapFill was misinterpreted.
  3. When the [invisible] heartbeat arrived at 6:31:07 your alarm says you received 3, expected 4. You should have been expecting 5.

The rest of the log repeats the same scenario over the next hour.

Dean Kauffman

> Congratulations for breaking the record on the longest post to fixprotocol.org :wink:
>
> I have looked at the first few messages and have some comments :
>
> 1. The FIX session initiator (not you) sends an initial Logon message with ResetSeqNumFlag(141)=Y.
> It seems to me to be unclear from the specification as to whether this is “approved” usage of this field or not. This field is documented explicitly for maintaining 24 hour connectivity when a logon is sent over an already established session in order to effectively reset the sequence numbers without disconnecting. Having experienced many problems with non-24 hour connectivity whereby one end of a session forgot to (manually) reset the sequence numbers overnight, it would be helpful to use the ResetSeqNumFlag on an initial Logon message when you really were expecting the sequence numbers to have been reset anyway. I notice that CME requires this behavior.
> Either way, the acceptor (you) sends a reject to the logon request as it deems ResetSeqNumFlag=Y on an initial Logon message to be invalid and then it disconnects. This behavior could easily be considered reasonable.
> 2. The initiator tries to Logon again. This time the Logon is now sent with MsgSeqNum=2 and ResetSeqNumFlag=N. The acceptor is OK with this and sends a logon in response. The acceptor also sends a ResendRequest message to request the resending of ONLY MsgSeqNum=1 because it didn’t store the previously received “invalid” Logon message. This isn’t perfect as maybe it should have stored the previously received Logon message, given the fact that it chose to respond to it, but it isn’t catastrophic.
> 3. The initiator responds to the ResendRequest, in my humble opinion, with a slightly poor response. It sent a SequenceReset-gap fill message with MsgSeqNum=1, NewSeqNo=3. Why did it not have NewSeqNo=2 given the fact that you only asked for a resend of [1,1]?
> 4. The acceptor (you) then over-reacts to the resending of MsgSeqNum=1, in my humble opinion. As your FIX engine is using the “resend requests to explicitly fill a gap” system rather than the more recommended “resend requests thru infinity” method, it should be prepared to receive a SequenceReset-gap fill message that spans beyond the range it requests. It should just treat that as completely filling the gap and be done with it.
>
> Summary:
>
> Both initiator and acceptor are misbehaving.
>
> The actual breakdown in the early part of the log is due to the acceptor (you) when processing a SequenceReset-gap fill message that more-than-fills the gap that you requested to be filled with a ResendRequest message.
>
> I didn’t have the time to look any further in your log than that.
>
> I hope this helps.
>
> [Over to you Ryan & Scott to correct my mistakes :wink: ]
>

4

[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
Here is a corrected response:

John’s assessments are on track. Here’s my reading:

Remote errors include:

  1. [Logon 141=Y] is only needed in a 24-hour connection. But this should not be fatal.
  2. Response to [ResendRequest 1-1] should be [GapFill 1-2] not [GapFill 1-3]. But this again should not be fatal.
  3. We don’t see heartbeats here, but the interval is 60 seconds and the fatal error occurs 60 seconds after the “Sequence reset” log. Judging from the logs the [invisible] heartbeat at 6:31:07 was sent with sequence 3 but should have been sent with 4.

Local errors include:

  1. Denial of a Logon should be Logout, not Reject. Including 141=Y is not a session-level rule violation and could be interpreted as confirmation that requestor is at start-of-day.
  2. Receiving [GapFill 1-3] should not reset your next-expected sequence number. You have messages 2 and 3 in hand and you didn’t ask to have them resent. Also the ERROR alarm seems to imply that the GapFill was misinterpreted.

When the [invisible] heartbeat arrived at 6:31:07 your alarm says you received 3, expected 4 and terminated the session. This behavior is correct.

The rest of the log repeats the same scenario over the next hour.

Dean Kauffman

> > Congratulations for breaking the record on the longest post to fixprotocol.org :wink:
> >
> > I have looked at the first few messages and have some comments :
> >
> > 1. The FIX session initiator (not you) sends an initial Logon message with ResetSeqNumFlag(141)=Y.
> > It seems to me to be unclear from the specification as to whether this is “approved” usage of this field or not. This field is documented explicitly for maintaining 24 hour connectivity when a logon is sent over an already established session in order to effectively reset the sequence numbers without disconnecting. Having experienced many problems with non-24 hour connectivity whereby one end of a session forgot to (manually) reset the sequence numbers overnight, it would be helpful to use the ResetSeqNumFlag on an initial Logon message when you really were expecting the sequence numbers to have been reset anyway. I notice that CME requires this behavior.
> > Either way, the acceptor (you) sends a reject to the logon request as it deems ResetSeqNumFlag=Y on an initial Logon message to be invalid and then it disconnects. This behavior could easily be considered reasonable.
> > 2. The initiator tries to Logon again. This time the Logon is now sent with MsgSeqNum=2 and ResetSeqNumFlag=N. The acceptor is OK with this and sends a logon in response. The acceptor also sends a ResendRequest message to request the resending of ONLY MsgSeqNum=1 because it didn’t store the previously received “invalid” Logon message. This isn’t perfect as maybe it should have stored the previously received Logon message, given the fact that it chose to respond to it, but it isn’t catastrophic.
> > 3. The initiator responds to the ResendRequest, in my humble opinion, with a slightly poor response. It sent a SequenceReset-gap fill message with MsgSeqNum=1, NewSeqNo=3. Why did it not have NewSeqNo=2 given the fact that you only asked for a resend of [1,1]?
> > 4. The acceptor (you) then over-reacts to the resending of MsgSeqNum=1, in my humble opinion. As your FIX engine is using the “resend requests to explicitly fill a gap” system rather than the more recommended “resend requests thru infinity” method, it should be prepared to receive a SequenceReset-gap fill message that spans beyond the range it requests. It should just treat that as completely filling the gap and be done with it.
> >
> > Summary:
> >
> > Both initiator and acceptor are misbehaving.
> >
> > The actual breakdown in the early part of the log is due to the acceptor (you) when processing a SequenceReset-gap fill message that more-than-fills the gap that you requested to be filled with a ResendRequest message.
> >
> > I didn’t have the time to look any further in your log than that.
> >
> > I hope this helps.
> >
> > [Over to you Ryan & Scott to correct my mistakes :wink: ]
> >
>