Imported from previous forum
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
[ original email was from John Greenan - 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
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
[ original email was from Robert Benoit - 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 caseSuppose 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 101Or 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
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 caseSuppose 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 101Or 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
[ original email was from John Greenan - 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 caseSuppose 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 101Or 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
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 caseSuppose 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 101Or 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
[ original email was from James Bywater - 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
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 caseSuppose 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:
- You send a Logon request with SeqNo 101
- The counterparty expects SeqNo 100 (it missed the QuoteRequest), but
- … first acknowledges the Logon by sending a Logon back and
- … 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