Responding to Logon conflicts?

, ,
1

Imported from previous forum

2

Hi All,

I’m curious as to the correct way a FIX engine should respond to the receipt of a logon from a peer that collides with a session that is already active from a different peer - should the engine send a response message (with a default sequence number) or should the engine simply disconnect with no response to the offending client?

Thanks,

Russ

3

Hi Russ,

The following is from the FIX.4.4 spec (http://fixprotocol.org/specifications/FIX.4.4, volume 2, page 29):

“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.”

  • Paul

Hi All,

I’m curious as to the correct way a FIX engine should respond to the
receipt of a logon from a peer that collides with a session that is
already active from a different peer - should the engine send a response
message (with a default sequence number) or should the engine simply
disconnect with no response to the offending client?

Thanks,

Russ

4

Hi Russ,

The following is from the FIX.4.4 spec
(http://fixprotocol.org/specifications/FIX.4.4, volume 2, page 29):

"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.

Hi Paul,

Thanks - that’s pretty much what I thought, but I had received an email from someone who wasn’t happy with QuickFix doing that so I was wondering if other engines were doing something different.

It would be nice if FIX included an informational message type that could be used in these situations, e.g. one where the sequencer number was not relevant. It seems there are several situations where receiving a response message would be beneficial to the connecting system.

Cheers,

Russ

5

Hi Russ,

The following is from the FIX.4.4 spec
(http://fixprotocol.org/specifications/FIX.4.4, volume 2, page 29):

"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.

Hi Paul,

Thanks - that’s pretty much what I thought, but I had received an email
from someone who wasn’t happy with QuickFix doing that so I was
wondering if other engines were doing something different.

It would be nice if FIX included an informational message type that
could be used in these situations, e.g. one where the sequencer number
was not relevant. It seems there are several situations where receiving
a response message would be beneficial to the connecting system.

Cheers,

Russ

I agree wholeheartedly, Russ. It is completely unclear to the third party in this scenario as to why logon messages sent are unanswered. It would be much more helpful in diagnosing the root cause for that party if at least some message were sent, even if it were just an admin-level reject versus a logout message. If the FIX engine were smart enough, it wouldn’t up the sequence number for that session if it were already active when it received another logon request and it decided to send a notification to the third party. Just my two cents.

  • Paul
6

Hi Russ,

The following is from the FIX.4.4 spec
(http://fixprotocol.org/specifications/FIX.4.4, volume 2, page 29):

"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.

Hi Paul,

Thanks - that’s pretty much what I thought, but I had received an
email from someone who wasn’t happy with QuickFix doing that so I was
wondering if other engines were doing something different.

It would be nice if FIX included an informational message type that
could be used in these situations, e.g. one where the sequencer
number was not relevant. It seems there are several situations
where receiving a response message would be beneficial to the
connecting system.

Cheers,

Russ

I agree wholeheartedly, Russ. It is completely unclear to the third
party in this scenario as to why logon messages sent are unanswered. It
would be much more helpful in diagnosing the root cause for that party
if at least some message were sent, even if it were just an admin-level
reject versus a logout message. If the FIX engine were smart enough, it
wouldn’t up the sequence number for that session if it were already
active when it received another logon request and it decided to send a
notification to the third party. Just my two cents.

  • Paul

FIX connectivity may not always be on private lines. If it is an anonymous user/hacker who is trying to connect, it is worth not sending anything back but simply drop the connection request. My 2 cents.

-Chirag

7

Hi Russ,

The following is from the FIX.4.4 spec
(http://fixprotocol.org/specifications/FIX.4.4, volume 2, page
29):

"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.

Hi Paul,

Thanks - that’s pretty much what I thought, but I had received an
email from someone who wasn’t happy with QuickFix doing that so I
was wondering if other engines were doing something different.

It would be nice if FIX included an informational message type that
could be used in these situations, e.g. one where the sequencer
number was not relevant. It seems there are several situations where
receiving a response message would be beneficial to the connecting
system.

Cheers,

Russ

I agree wholeheartedly, Russ. It is completely unclear to the third
party in this scenario as to why logon messages sent are unanswered.
It would be much more helpful in diagnosing the root cause for that
party if at least some message were sent, even if it were just an admin-
level reject versus a logout message. If the FIX engine were smart
enough, it wouldn’t up the sequence number for that session if it were
already active when it received another logon request and it decided
to send a notification to the third party. Just my two cents.

  • Paul

FIX connectivity may not always be on private lines. If it is an
anonymous user/hacker who is trying to connect, it is worth not sending
anything back but simply drop the connection request. My 2 cents.

-Chirag

Chirag- correct we were concerned about denial of service attacks. Modifying to provide a response without consuming a sequence number would be an amelioration to the denial of service impact but is a fairly large change to the protocol.

8

Hi Russ,

The following is from the FIX.4.4 spec
(http://fixprotocol.org/specifications/FIX.4.4, volume 2, page
29):

"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.

Hi Paul,

Thanks - that’s pretty much what I thought, but I had received an
email from someone who wasn’t happy with QuickFix doing that so I
was wondering if other engines were doing something different.

It would be nice if FIX included an informational message type that
could be used in these situations, e.g. one where the sequencer
number was not relevant. It seems there are several situations where
receiving a response message would be beneficial to the connecting
system.

Cheers,

Russ

I agree wholeheartedly, Russ. It is completely unclear to the third
party in this scenario as to why logon messages sent are unanswered.
It would be much more helpful in diagnosing the root cause for that
party if at least some message were sent, even if it were just an admin-
level reject versus a logout message. If the FIX engine were smart
enough, it wouldn’t up the sequence number for that session if it were
already active when it received another logon request and it decided
to send a notification to the third party. Just my two cents.

  • Paul

FIX connectivity may not always be on private lines. If it is an
anonymous user/hacker who is trying to connect, it is worth not sending
anything back but simply drop the connection request. My 2 cents.

-Chirag

I agree, but if the connection is over a public line, you should probably be using encryption anyway. Otherwise, all the traffic is in plain text. A net-to-net VPN is always nice, but as you said, not always available or practical. I hate to use the ‘C’ word, but this would be great to have as a configurable option so that if you know you’re on a private line you could configure the engine to send a message in response, but if it’s public you could simply drop the connection attempt with no reply. Again, there are plenty of ways to manage privacy, and I certainly don’t have experience with each and every one.

  • Paul
9

I agree with Paul. In my experience with Appia, the acceptor does not respond back to the second initiator but simply disconnects it.

Hi Russ,

The following is from the FIX.4.4 spec
(http://fixprotocol.org/specifications/FIX.4.4, volume 2, page 29):

“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.”

  • Paul

Hi All,

I’m curious as to the correct way a FIX engine should respond to the
receipt of a logon from a peer that collides with a session that is
already active from a different peer - should the engine send a
response message (with a default sequence number) or should the engine
simply disconnect with no response to the offending client?

Thanks,

Russ