# exact procedure to recover from fatal error condition / disconnect **URL:** \ **Category:** General Q&A\ **Tags:** general-qa, xid\_167416, imported\ **Created:** [August 10, 2006, 11:11am UTC](https://forum.fixtrading.org/t/exact-procedure-to-recover-from-fatal-error-condition-disconnect/4222 "2006-08-10T11:11:28Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![brunocassiman74\_x](https://avatars.discourse-cdn.com/v4/letter/b/3ec8ea/32.png) [@brunocassiman74\_x](https://forum.fixtrading.org/u/brunocassiman74_x)\ **Post date:** [August 10, 2006, 11:11am UTC](https://forum.fixtrading.org/t/exact-procedure-to-recover-from-fatal-error-condition-disconnect/4222/1 "2006-08-10T11:11:28Z")
Imported from previous forum ---
**Author:** ![brunocassiman74\_x](https://avatars.discourse-cdn.com/v4/letter/b/3ec8ea/32.png) [@brunocassiman74\_x](https://forum.fixtrading.org/u/brunocassiman74_x)\ **Post date:** [August 10, 2006, 11:11am UTC](https://forum.fixtrading.org/t/exact-procedure-to-recover-from-fatal-error-condition-disconnect/4222/2 "2006-08-10T11:11:28Z")
Hi all, I am in the process of implementing a custom FIX engine (FIX4.2) I wonder what message to send when i open a new socket connection after the connection has been broken / interrupted. Do I send a SequenceReset or Logon with ResetSeqNumFlag, or do I just continue sending messages where I left off. Thanks in advance ---
**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\ **Post date:** [August 10, 2006, 11:44am UTC](https://forum.fixtrading.org/t/exact-procedure-to-recover-from-fatal-error-condition-disconnect/4222/3 "2006-08-10T11:44:51Z")
[original email was from John Greenan - [john.greenan@alignment-systems.com](mailto:john.greenan@alignment-systems.com) ] Hi Bruno, I’d refer you to the FIX 4.2 specification page 15 - “After authentication, the initiator and acceptor must synchronize their messages through interrogation of the MsgSeqNum field before sending any queued or new messages. A comparison of the MsgSeqNum in the Logon message to the internally monitored next expected sequence number will indicate any message gaps. Likewise, the initiator can detect gaps by comparing the acknowledgment Logon message MsgSeqNum to the next expected value. The section on message recovery later in this document deals with message gap handling.” Basically, you should try and continue from where you left off - synchronise sequence numbers (re-sending where appropriate) and get back to a good state of the world, then continue as normal. Good luck! > Hi all, > > I am in the process of implementing a custom FIX engine (FIX4.2) I > wonder what message to send when i open a new socket connection after > the connection has been broken / interrupted. Do I send a SequenceReset > or Logon with ResetSeqNumFlag, or do I just continue sending messages > where I left off. > > Thanks in advance ---
**Author:** ![brunocassiman74\_x](https://avatars.discourse-cdn.com/v4/letter/b/3ec8ea/32.png) [@brunocassiman74\_x](https://forum.fixtrading.org/u/brunocassiman74_x)\ **Post date:** [August 10, 2006, 12:17pm UTC](https://forum.fixtrading.org/t/exact-procedure-to-recover-from-fatal-error-condition-disconnect/4222/4 "2006-08-10T12:17:52Z")
Thanks for the reply. As I understand ‘authentication’, this would mean sending a Logon Message, correct ? On another thread I read that a mid session logon would make the Fixserver disconnect because it does not expect such a message. Can you tell me what the first message that my engine needs to send in the following case Suppose a QuoteRequest message with Seqnum 100 fails transmission because of the comm. link being broken. My software establishes a new socketconnection. Case A: Send Logon message with SeqNo 101 Case B: Send TestRequest with SeqNo 101 Or something else … Thanks in advance It is a bit unclear > Hi Bruno, > > I’d refer you to the FIX 4.2 specification page 15 - > > “After authentication, the initiator and acceptor must synchronize their > messages through interrogation of the MsgSeqNum field before sending any > queued or new messages. A comparison of the MsgSeqNum in the Logon > message to the internally monitored next expected sequence number will > indicate any message gaps. Likewise, the initiator can detect gaps by > comparing the acknowledgment Logon message MsgSeqNum to the next > expected value. The section on message recovery later in this document > deals with message gap handling.” > > Basically, you should try and continue from where you left off - > synchronise sequence numbers (re-sending where appropriate) and get back > to a good state of the world, then continue as normal. > > Good luck! > > > Hi all, > > > > I am in the process of implementing a custom FIX engine (FIX4.2) I > > wonder what message to send when i open a new socket connection after > > the connection has been broken / interrupted. Do I send a > > SequenceReset or Logon with ResetSeqNumFlag, or do I just continue > > sending messages where I left off. > > > > Thanks in advance ---
**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\ **Post date:** [August 10, 2006, 1:58pm UTC](https://forum.fixtrading.org/t/exact-procedure-to-recover-from-fatal-error-condition-disconnect/4222/5 "2006-08-10T13:58:24Z")
[original email was from Robert Benoit - [Robert.Benoit@transacttools.net](mailto:Robert.Benoit@transacttools.net) ] Bruno, The first message sent across the wire after a “re-connection” of the socket should be a logon. If you are the initiator you should send a logon, then a test request. A FixServer will disconnect if a logon message is sent on a session that has already been established. Bob Benoit TransactTools Inc. > Thanks for the reply. > > As I understand ‘authentication’, this would mean sending a Logon > Message, correct ? On another thread I read that a mid session logon > would make the Fixserver disconnect because it does not expect such a > message. Can you tell me what the first message that my engine needs to > send in the following case > > Suppose a QuoteRequest message with Seqnum 100 fails transmission > because of the comm. link being broken. My software establishes a new > socketconnection. > > Case A: Send Logon message with SeqNo 101 Case B: Send TestRequest > with SeqNo 101 > > Or something else … > > Thanks in advance > > It is a bit unclear > > > Hi Bruno, > > > > I’d refer you to the FIX 4.2 specification page 15 - > > > > “After authentication, the initiator and acceptor must synchronize > > their messages through interrogation of the MsgSeqNum field before > > sending any queued or new messages. A comparison of the MsgSeqNum in > > the Logon message to the internally monitored next expected sequence > > number will indicate any message gaps. Likewise, the initiator can > > detect gaps by comparing the acknowledgment Logon message MsgSeqNum to > > the next expected value. The section on message recovery later in this > > document deals with message gap handling.” > > > > Basically, you should try and continue from where you left off - > > synchronise sequence numbers (re-sending where appropriate) and get > > back to a good state of the world, then continue as normal. > > > > Good luck! > > > > > Hi all, > > > > > > I am in the process of implementing a custom FIX engine (FIX4.2) I > > > wonder what message to send when i open a new socket connection > > > after the connection has been broken / interrupted. Do I send a > > > SequenceReset or Logon with ResetSeqNumFlag, or do I just continue > > > sending messages where I left off. > > > > > > Thanks in advance ---
**Author:** ![brunocassiman74\_x](https://avatars.discourse-cdn.com/v4/letter/b/3ec8ea/32.png) [@brunocassiman74\_x](https://forum.fixtrading.org/u/brunocassiman74_x)\ **Post date:** [August 10, 2006, 2:27pm UTC](https://forum.fixtrading.org/t/exact-procedure-to-recover-from-fatal-error-condition-disconnect/4222/6 "2006-08-10T14:27:42Z")
Thanks for the input. > Bruno, > > The first message sent across the wire after a “re-connection” of the > socket should be a logon. > > If you are the initiator you should send a logon, then a test request. > > A FixServer will disconnect if a logon message is sent on a session that > has already been established. > > Bob Benoit TransactTools Inc. > > > Thanks for the reply. > > > > As I understand ‘authentication’, this would mean sending a Logon > > Message, correct ? On another thread I read that a mid session logon > > would make the Fixserver disconnect because it does not expect such a > > message. Can you tell me what the first message that my engine needs > > to send in the following case > > > > Suppose a QuoteRequest message with Seqnum 100 fails transmission > > because of the comm. link being broken. My software establishes a new > > socketconnection. > > > > Case A: Send Logon message with SeqNo 101 Case B: Send TestRequest > > with SeqNo 101 > > > > Or something else … > > > > Thanks in advance > > > > It is a bit unclear > > > > > Hi Bruno, > > > > > > I’d refer you to the FIX 4.2 specification page 15 - > > > > > > “After authentication, the initiator and acceptor must synchronize > > > their messages through interrogation of the MsgSeqNum field before > > > sending any queued or new messages. A comparison of the MsgSeqNum in > > > the Logon message to the internally monitored next expected sequence > > > number will indicate any message gaps. Likewise, the initiator can > > > detect gaps by comparing the acknowledgment Logon message MsgSeqNum > > > to the next expected value. The section on message recovery later in > > > this document deals with message gap handling.” > > > > > > Basically, you should try and continue from where you left off - > > > synchronise sequence numbers (re-sending where appropriate) and get > > > back to a good state of the world, then continue as normal. > > > > > > Good luck! > > > > > > > Hi all, > > > > > > > > I am in the process of implementing a custom FIX engine (FIX4.2) I > > > > wonder what message to send when i open a new socket connection > > > > after the connection has been broken / interrupted. Do I send a > > > > SequenceReset or Logon with ResetSeqNumFlag, or do I just continue > > > > sending messages where I left off. > > > > > > > > Thanks in advance ---
**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\ **Post date:** [August 10, 2006, 2:13pm UTC](https://forum.fixtrading.org/t/exact-procedure-to-recover-from-fatal-error-condition-disconnect/4222/7 "2006-08-10T14:13:46Z")
[original email was from John Greenan - [john.greenan@alignment-systems.com](mailto:john.greenan@alignment-systems.com) ] You say “Suppose a QuoteRequest message with Seqnum 100 fails transmission because of the comm. link being broken”. How do you know that the communications link is broken? If you think of a 7 layer networking stack (the OSI model) then FIX provides 7,6 and 5. If you have a failure below those levels then perhaps you need to look at those layers. Normally you find a connection has failed by (a) your counterparty starts shouting (b) your network monitoring software picks up something (c) the heartbeats are not getting through, so your sequencing will be screwed up. If you can fix the comms layer problem without the FIX layer getting involved then do so - FIX is not really bothered about transport - quote from 4.2 spec “It does not demand a single type of carrier (e.g., it will work with leased lines, frame relay, Internet, etc.), nor a single security protocol.” “A single FIX session can exist across multiple physical connections. Parties can connect and disconnect multiple times while maintaining a single FIX session.” So, if you realise that the comms link is broken, but your counterparty does not, then why not just reconnect your socket or whatever and keep going? If your counterparty has recognised that you are no longer connected then - quote “Termination by other means should be considered an abnormal condition and dealt with as an error. Session termination without receiving a Logout should treat the counterparty as logged out.” So in the case where your counterparty realises that you are disconnected you would then have to log in again by sending a Logon message. It makes sense to regard a mid session login request as a failure and to disconnect as it would appear to the acceptor that the initiator is having some kind of problem. Then the session can be restarted by the initiator. Talk to your counterparty as well and see if they have any quirks on how they want to handle this. Often firms have developed their own slight twists on the protocol to handle trading system, comms or FIX engine bugs/‘features’ so they going to be useful people to talk to. > Thanks for the reply. > > As I understand ‘authentication’, this would mean sending a Logon > Message, correct ? On another thread I read that a mid session logon > would make the Fixserver disconnect because it does not expect such a > message. Can you tell me what the first message that my engine needs to > send in the following case > > Suppose a QuoteRequest message with Seqnum 100 fails transmission > because of the comm. link being broken. My software establishes a new > socketconnection. > > Case A: Send Logon message with SeqNo 101 Case B: Send TestRequest > with SeqNo 101 > > Or something else … > > Thanks in advance > > It is a bit unclear > > > Hi Bruno, > > > > I’d refer you to the FIX 4.2 specification page 15 - > > > > “After authentication, the initiator and acceptor must synchronize > > their messages through interrogation of the MsgSeqNum field before > > sending any queued or new messages. A comparison of the MsgSeqNum in > > the Logon message to the internally monitored next expected sequence > > number will indicate any message gaps. Likewise, the initiator can > > detect gaps by comparing the acknowledgment Logon message MsgSeqNum to > > the next expected value. The section on message recovery later in this > > document deals with message gap handling.” > > > > Basically, you should try and continue from where you left off - > > synchronise sequence numbers (re-sending where appropriate) and get > > back to a good state of the world, then continue as normal. > > > > Good luck! > > > > > Hi all, > > > > > > I am in the process of implementing a custom FIX engine (FIX4.2) I > > > wonder what message to send when i open a new socket connection > > > after the connection has been broken / interrupted. Do I send a > > > SequenceReset or Logon with ResetSeqNumFlag, or do I just continue > > > sending messages where I left off. > > > > > > Thanks in advance ---
**Author:** ![brunocassiman74\_x](https://avatars.discourse-cdn.com/v4/letter/b/3ec8ea/32.png) [@brunocassiman74\_x](https://forum.fixtrading.org/u/brunocassiman74_x)\ **Post date:** [August 10, 2006, 2:30pm UTC](https://forum.fixtrading.org/t/exact-procedure-to-recover-from-fatal-error-condition-disconnect/4222/8 "2006-08-10T14:30:32Z")
I “know” that the comm. link is broken if I can’t transmit bytes over the socket anymore, I simply get an exception. In this case I need to reconnect the socket, which in fact is a new connection to the RSP provider. Thanks for your input. Regards, Bruno > You say “Suppose a QuoteRequest message with Seqnum 100 fails > transmission because of the comm. link being broken”. How do you know > that the communications link is broken? If you think of a 7 layer > networking stack (the OSI model) then FIX provides 7,6 and 5. If you > have a failure below those levels then perhaps you need to look at > those layers. > > Normally you find a connection has failed by (a) your counterparty > starts shouting (b) your network monitoring software picks up something > (c) the heartbeats are not getting through, so your sequencing will be > screwed up. > > If you can fix the comms layer problem without the FIX layer getting > involved then do so - FIX is not really bothered about transport > > - quote from 4.2 spec “It does not demand a single type of carrier > (e.g., it will work with leased lines, frame relay, Internet, etc.), > nor a single security protocol.” “A single FIX session can exist > across multiple physical connections. Parties can connect and > disconnect multiple times while maintaining a single FIX session.” > > So, if you realise that the comms link is broken, but your counterparty > does not, then why not just reconnect your socket or whatever and keep > going? If your counterparty has recognised that you are no longer > connected then - quote “Termination by other means should be considered > an abnormal condition and dealt with as an error. Session termination > without receiving a Logout should treat the counterparty as logged out.” > > So in the case where your counterparty realises that you are > disconnected you would then have to log in again by sending a Logon > message. It makes sense to regard a mid session login request as a > failure and to disconnect as it would appear to the acceptor that the > initiator is having some kind of problem. Then the session can be > restarted by the initiator. > > Talk to your counterparty as well and see if they have any quirks on how > they want to handle this. Often firms have developed their own slight > twists on the protocol to handle trading system, comms or FIX engine > bugs/‘features’ so they going to be useful people to talk to. > > > Thanks for the reply. > > > > As I understand ‘authentication’, this would mean sending a Logon > > Message, correct ? On another thread I read that a mid session logon > > would make the Fixserver disconnect because it does not expect such a > > message. Can you tell me what the first message that my engine needs > > to send in the following case > > > > Suppose a QuoteRequest message with Seqnum 100 fails transmission > > because of the comm. link being broken. My software establishes a new > > socketconnection. > > > > Case A: Send Logon message with SeqNo 101 Case B: Send TestRequest > > with SeqNo 101 > > > > Or something else … > > > > Thanks in advance > > > > It is a bit unclear > > > > > Hi Bruno, > > > > > > I’d refer you to the FIX 4.2 specification page 15 - > > > > > > “After authentication, the initiator and acceptor must synchronize > > > their messages through interrogation of the MsgSeqNum field before > > > sending any queued or new messages. A comparison of the MsgSeqNum in > > > the Logon message to the internally monitored next expected sequence > > > number will indicate any message gaps. Likewise, the initiator can > > > detect gaps by comparing the acknowledgment Logon message MsgSeqNum > > > to the next expected value. The section on message recovery later in > > > this document deals with message gap handling.” > > > > > > Basically, you should try and continue from where you left off - > > > synchronise sequence numbers (re-sending where appropriate) and get > > > back to a good state of the world, then continue as normal. > > > > > > Good luck! > > > > > > > Hi all, > > > > > > > > I am in the process of implementing a custom FIX engine (FIX4.2) I > > > > wonder what message to send when i open a new socket connection > > > > after the connection has been broken / interrupted. Do I send a > > > > SequenceReset or Logon with ResetSeqNumFlag, or do I just continue > > > > sending messages where I left off. > > > > > > > > Thanks in advance ---
**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\ **Post date:** [August 10, 2006, 2:34pm UTC](https://forum.fixtrading.org/t/exact-procedure-to-recover-from-fatal-error-condition-disconnect/4222/9 "2006-08-10T14:34:08Z")
[original email was from James Bywater - [jb@cameronsystems.com](mailto:jb@cameronsystems.com) ] \> Normally you find a connection has failed by (a) your counterparty > starts shouting (b) your network monitoring software picks up something > (c) the heartbeats are not getting through, so your sequencing will be > screwed up. In Java, for example, you might receive an Exception which indicates that the underlying TCP session has been closed. This would indicate a disconnection without a logout message - see below: > “A single FIX session can exist > across multiple physical connections. Parties can connect and > disconnect multiple times while maintaining a single FIX session.” > “Termination by other means should be considered > an abnormal condition and dealt with as an error. Session termination > without receiving a Logout should treat the counterparty as logged out.” > > So in the case where your counterparty realises that you are > disconnected you would then have to log in again by sending a Logon > message. These two parts of the spec seem to contradict each other - I think that it’s reasonable to assume that some people may have interpreted it differently than others. > It makes sense to regard a mid session login request as a > failure and to disconnect as it would appear to the acceptor that the > initiator is having some kind of problem. Then the session can be > restarted by the initiator. However from the FIX security document: “The LOGON message is also used to change the session key in the middle of an active session.” So there is another contradiction (albeit not in the same document). I believe that the second usage is not widely used, however. Regards, James ---
**Author:** ![jorgthonnes](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/jorgthonnes/32/196_2.png) [@jorgthonnes](https://forum.fixtrading.org/u/jorgthonnes)\ **Post date:** [August 10, 2006, 3:00pm UTC](https://forum.fixtrading.org/t/exact-procedure-to-recover-from-fatal-error-condition-disconnect/4222/10 "2006-08-10T15:00:24Z")
> Thanks for the reply. > > As I understand ‘authentication’, this would mean sending a Logon > Message, correct ? On another thread I read that a mid session logon > would make the Fixserver disconnect because it does not expect such a > message. Can you tell me what the first message that my engine needs to > send in the following case > > Suppose a QuoteRequest message with Seqnum 100 fails transmission > because of the comm. link being broken. My software establishes a new > socketconnection. > > Case A: Send Logon message with SeqNo 101 > Case B: Send TestRequest with SeqNo 101 The procedure is as follows: 1. You send a Logon request with SeqNo 101 2. The counterparty expects SeqNo 100 (it missed the QuoteRequest), but 3. … first acknowledges the Logon by sending a Logon back and 4. … sends a ResendRequest(100:100) or (100:INFINITY) In the meanwhile, you may have sent a TestRequest which is answered by the other side as soon as their ResendRequest is finished. If you wait for the answer to your TestRequest(ID), which is Heartbeat(ID) before sending any further business messages, you can be sure that the recovery of lost messsages has been completed. If the Logon ACK from the other side has a SeqNo higher than expected from your side, you have missed some messages from the counterparty and you will also issue a ResendRequest (before sending the TestRequest). Hope that clarifies the FIX side of the things a bit. Cheers, Jörg