Imported from previous forum
I have a client who uses a FIX engine that does an odd thing (IMO, anyway). When any FIX connection is lost their engine sends a Logon to every FIX connection they have, not just the one that died. My FIX engine (QuickFIX) doesn’t like receiving this second mid-session Logon and it gracefully ends the session, sends a Logout, etc.
I’ve been looking at the FIX 4.2 standard and I can’t seem to find a definitive answer to what a FIX engine should do when it receives an unexpected Logon in the middle of a session. Should it ignore it? End the session like QuickFIX does?
Any help appreciated. Thanks.
Starting with FIX 4.3, a volume 2 was added to the FIX specs to clarify detailed session-level cases such as this. Test case 1S, condition b says:
Logon message received with duplicate identity (e.g. same IP, port, SenderCompID, TargetCompID, etc. as existing connection)
should be handled this way:
- Generate an “error” condition in test output.
- Disconnect without sending a message (note sending a Reject or
Logout would consume a MsgSeqNum)
Hope that helps,
David Rhodes
TransactTools
I have a client who uses a FIX engine that does an odd thing (IMO,
anyway). When any FIX connection is lost their engine sends a Logon to
every FIX connection they have, not just the one that died. My FIX
engine (QuickFIX) doesn’t like receiving this second mid-session Logon
and it gracefully ends the session, sends a Logout, etc.I’ve been looking at the FIX 4.2 standard and I can’t seem to find a
definitive answer to what a FIX engine should do when it receives an
unexpected Logon in the middle of a session. Should it ignore it? End
the session like QuickFIX does?Any help appreciated. Thanks.
Thanks, David. This case seems to cover exactly the situation I’m experiencing, and QuickFIX seems to be doing the right thing by disconnecting. I’ll run this spec by my client and see what they have to say about it. Thanks a million.
Starting with FIX 4.3, a volume 2 was added to the
FIX specs to clarify detailed session-level cases
such as this. Test case 1S, condition b says:Logon message received with duplicate identity (e.g.
same IP, port, SenderCompID, TargetCompID, etc. as
existing connection)should be handled this way:
- Generate an “error” condition in test output.
- Disconnect without sending a message (note
sending a Reject or Logout would consume a
MsgSeqNum)Hope that helps,
David Rhodes TransactTools
I have a client who uses a FIX engine that does an
odd thing (IMO, anyway). When any FIX connection
is lost their engine sends a Logon to every
FIX connection they have, not just the one that
died. My FIX engine (QuickFIX) doesn’t like
receiving this second mid-session Logon and it
gracefully ends the session, sends a Logout, etc.I’ve been looking at the FIX 4.2 standard and
I can’t seem to find a definitive answer to
what a FIX engine should do when it receives
an unexpected Logon in the middle of a
session. Should it ignore it? End the session like
QuickFIX does?Any help appreciated. Thanks.
Do they set the ResetSeqNumFlag or do they just send a normal logon?
Is the sequence number the one you are expecting?
Regardless of that this seems like a bug on their part. That said you should probably treat it like a temporary loss of connectivity(It could have been), and not end the session but instead respond to the logon.
I have a client who uses a FIX engine that does an odd thing (IMO,
anyway). When any FIX connection is lost their engine sends a Logon to
every FIX connection they have, not just the one that died. My FIX
engine (QuickFIX) doesn’t like receiving this second mid-session Logon
and it gracefully ends the session, sends a Logout, etc.I’ve been looking at the FIX 4.2 standard and I can’t seem to find a
definitive answer to what a FIX engine should do when it receives an
unexpected Logon in the middle of a session. Should it ignore it? End
the session like QuickFIX does?Any help appreciated. Thanks.
No ResetSeqNumFlag, just the normal logon with the expected sequence number. According to David’s post, the spec says in this situation the engine should disconnect, and that’s what mine does. I’m going to have my folks speak with our client about their interpretation of the spec, and more importantly, why they send a Logon to every session when only one goes down.
Do they set the ResetSeqNumFlag or do they just send
a normal logon? Is the sequence number the one you
are expecting?Regardless of that this seems like a bug on their
part. That said you should probably treat it like a
temporary loss of connectivity(It could have been),
and not end the session but instead respond to the
logon.I have a client who uses a FIX engine that does an
odd thing (IMO, anyway). When any FIX connection
is lost their engine sends a Logon to every
FIX connection they have, not just the one that
died. My FIX engine (QuickFIX) doesn’t like
receiving this second mid-session Logon and it
gracefully ends the session, sends a Logout, etc.I’ve been looking at the FIX 4.2 standard and
I can’t seem to find a definitive answer to
what a FIX engine should do when it receives
an unexpected Logon in the middle of a
session. Should it ignore it? End the session like
QuickFIX does?
Yes David’s post does seem to offer the best solution. The one difference between his solution(4.3 spec) and your engine’s current solution is that your engine sends a logout while the fix 4.3 spec advises otherwise:
- Disconnect without sending a message (note sending a Reject or Logout would consume a MsgSeqNum).
Probably not a big issue to do it either way.
No ResetSeqNumFlag, just the normal logon with the expected sequence
number. According to David’s post, the spec says in this situation the
engine should disconnect, and that’s what mine does. I’m going to have
my folks speak with our client about their interpretation of the spec,
and more importantly, why they send a Logon to every session when only
one goes down.Do they set the ResetSeqNumFlag or do they just send a normal logon?
Is the sequence number the one you are expecting?Regardless of that this seems like a bug on their part. That said
you should probably treat it like a temporary loss of
connectivity(It could have been), and not end the session but
instead respond to the logon.I have a client who uses a FIX engine that does an odd thing (IMO,
anyway). When any FIX connection is lost their engine sends a
Logon to every FIX connection they have, not just the one that
died. My FIX engine (QuickFIX) doesn’t like receiving this second
mid-session Logon and it gracefully ends the session, sends a
Logout, etc.I’ve been looking at the FIX 4.2 standard and I can’t seem to find a
definitive answer to what a FIX engine should do when it receives an
unexpected Logon in the middle of a session. Should it ignore it?
End the session like QuickFIX does?
Good catch. You are right that QuickFIX shouldn’t send a Logout according to the 3.3 spec. It seems there’s a problem on both sides: my client shouldn’t be expecting my FIX engine to quietly ignore a mid-session Logon, and my FIX enging shouldn’t be replying to that Logon with a Logout. Though hopefully if my client stops sending the Logout, I won’t have to address my FIX engine’s problem. 
Yes David’s post does seem to offer the best
solution. The one difference between his solution(4.3
spec) and your engine’s current solution is that your
engine sends a logout while the fix 4.3 spec advises
otherwise:
- Disconnect without sending a message (note
sending a Reject or Logout would consume a
MsgSeqNum).Probably not a big issue to do it either way.
No ResetSeqNumFlag, just the normal logon with the
expected sequence number. According to David’s
post, the spec says in this situation the engine
should disconnect, and that’s what mine does. I’m
going to have my folks speak with our client
about their interpretation of the spec, and more
importantly, why they send a Logon to every
session when only one goes down.Do they set the ResetSeqNumFlag or do they just?
send a normal logon Is the sequence number the ?
one you are expecting ?Regardless of that this seems like a bug on
their part. That said you should probably treat
it like a temporary loss of connectivity(It
could have been), and not end the session but
instead respond to the logon.I have a client who uses a FIX engine that
does an odd thing (IMO, anyway). When any
FIX connection is lost their engine sends a
Logon to every FIX connection they have,
not just the one that died. My FIX engine
(QuickFIX) doesn’t like receiving this second
mid-session Logon and it gracefully ends the
session, sends a Logout, etc.I’ve been looking at the FIX 4.2 standard and
I can’t seem to find a definitive answer to
what a FIX engine should do when it receives
an unexpected Logon in the middle of a
session. Should it ignore it? End the session
like QuickFIX does?
I’m actualy not sure the test scenario adequately describes the problem you are seeing. To go back to the testcase description:
“Logon message received with duplicate identity (e.g. same IP, port, SenderCompID, TargetCompID, etc. as existing connection)”
The “as existing connection” seems to me to imply that a new connection is coming in on the same IP and port that is attempting to logon with a session ID that is already active on another connection. In this case clearly you do not want to send a logout as it would consume a sequence number from the existing connection, so a disconnect is required. This is in fact what QuickFIX does in this scenario.
What you are seeing is a little different however. You are seeing a duplicate logon from the same connection that already established the session. In this case sending a logout is probably ok since you are not consuming a sequence number from an existing connection. I also don’t think this test case perfectly disambiguates the problem of what you do when a connection that has already logged on and sends another logon during the session on the existing connection.
Essentially I believe we went with the idea to send a logout whenever possible and in this case it can be done without causing sequence number problems. It would be nice if this exact scenario was clarified in the specification.
Good catch. You are right that QuickFIX shouldn’t send a Logout according to the 3.3 spec. It seems there’s a problem on both sides: my client shouldn’t be expecting my FIX engine to quietly ignore a mid-session Logon, and my FIX enging shouldn’t be replying to that Logon with a Logout. Though hopefully if my client stops sending the Logout, I won’t have to address my FIX engine’s problem.
I understand the distinction you have made and if your interpretation of “as existing connection” is correct (quite plausible), then the FIX standard doesn’t define expected behavior when another logon is received on an existing connection.
Regardless, I think it can be argued that sending such logons is a Bad Idea. At best it will cause the connection to terminate, and at worst it is completely unspecified.
I’m actualy not sure the test scenario adequately describes
the problem you are seeing. To go back to the testcase
description:“Logon message received with duplicate identity (e.g. same IP,
port, SenderCompID, TargetCompID, etc. as existing connection)”The “as existing connection” seems to me to imply that a
new connection is coming in on the same IP and port that is
attempting to logon with a session ID that is already active
on another connection. In this case clearly you do not want to
send a logout as it would consume a sequence number from the
existing connection, so a disconnect is required. This is in
fact what QuickFIX does in this scenario.What you are seeing is a little different however. You are
seeing a duplicate logon from the same connection that already
established the session. In this case sending a logout is
probably ok since you are not consuming a sequence number from
an existing connection. I also don’t think this test case
perfectly disambiguates the problem of what you do when a
connection that has already logged on and sends another logon
during the session on the existing connection.Essentially I believe we went with the idea to send a logout
whenever possible and in this case it can be done without
causing sequence number problems. It would be nice if this
exact scenario was clarified in the specification.Good catch. You are right that QuickFIX shouldn’t send
a Logout according to the 3.3 spec. It seems there’s a
problem on both sides: my client shouldn’t be expecting
my FIX engine to quietly ignore a mid- session Logon, and
my FIX enging shouldn’t be replying to that Logon with a
Logout. Though hopefully if my client stops sending the
Logout, I won’t have to address my FIX engine’s problem.
Agreed. I think the way to disambiguate it a bit is to specify that if the logon comes from another connection, disconnect immediately. If it comes from the existing connection, send a proper logout (The argument against taking up a sequence number doesn’t really make sense in this case, and the error text may be helpful in resolving the issue). Either way I definately think the connection should be terminated one way or the other. The way I essentially see this scenario is:
SERVER: “Hey, I think you’re logged in.”
CLIENT: “I’m not so sure”
SERVER: “Whoops! let’s start over!”
Unfortunately if their client doesn’t budge, we may have to allow for it through a configuration parameter. We had to do something similar to accomodate the CME sending messages with different compids on the same connection.
I understand the distinction you have made and if your interpretation of
“as existing connection” is correct (quite plausible), then the FIX
standard doesn’t define expected behavior when another logon is received
on an existing connection.Regardless, I think it can be argued that sending such logons is a Bad
Idea. At best it will cause the connection to terminate, and at worst it
is completely unspecified.
[ original email was from Matt Simpson - msimpson@cme.com ]
The GTC will look at capturing the distinction in the next release of Vol2.
CME practices mainstream behavior with respect to the handling of redundant Logons conducted over the same connection and responds with a Logout message. Also, it is not CME’s practice to send multiple SenderCompID’s over the same connection as we realize this would result in a potential disconnect on the receiving side.
Agreed. I think the way to disambiguate it a bit is to specify that if the logon comes from another connection, disconnect immediately. If it comes from the existing connection, send a proper logout (The argument against taking up a sequence number doesn’t really make sense in this case, and the error text may be helpful in resolving the issue). Either way I definately think the connection should be terminated one way or the other. The way I essentially see this scenario is:
SERVER: “Hey, I think you’re logged in.” CLIENT: “I’m not so sure”
SERVER: “Whoops! let’s start over!”Unfortunately if their client doesn’t budge, we may have to allow for it
through a configuration parameter. We had to do something similar to
accomodate the CME sending messages with different compids on the same
connection.I understand the distinction you have made and if your interpretation
of “as existing connection” is correct (quite plausible), then the FIX
standard doesn’t define expected behavior when another logon is
received on an existing connection.Regardless, I think it can be argued that sending such logons is a Bad
Idea. At best it will cause the connection to terminate, and at worst
it is completely unspecified.