Duplicate login

, ,
1

Imported from previous forum

2

[ original email was from Shakir Kagzi - shakir.kagzi@ftindia.com ]
Hi,

I have a question on duplicate login when the session is already connected (logged in).

How should the session handle when there is a duplicate login in current session? Should the sequence number increase or should the application do a session reject for the second attempt?

Or should the first login should also be logged off?

Thanks in advance.

3

Hi,

I have a question on duplicate login when the session is already
connected (logged in).

How should the session handle when there is a duplicate login in current
session? Should the sequence number increase or should the application
do a session reject for the second attempt?

Or should the first login should also be logged off?

Thanks in advance.

I have not found anything about this in the FIX specs. I guess that depends on the FIX engine implementation.
I did some testing with QuickFix and it seems to simply ignore the second logon request.

4

Hi,

I have a question on duplicate login when the session is already
connected (logged in).

How should the session handle when there is a duplicate login in
current session? Should the sequence number increase or should the
application do a session reject for the second attempt?

Or should the first login should also be logged off?

Thanks in advance.

I have not found anything about this in the FIX specs. I guess that
depends on the FIX engine implementation. I did some testing with
QuickFix and it seems to simply ignore the second logon request.

I too think that this depedns on the FIX engine implementation. Some of the engines that I have worked on discard the second lgin request as a session-level reject. One of them disconnected even the first session. So it depends on engine-to-engine.

Vikash

5

One of the key considerations in terms of responding to a duplicate or invalid logon request is for the acceptor to avoid consuming sequence numbers (sending Session Level Reject or Logout messages) if hit with a denial-of-service attack.

The FIX spec (Volume 2 in version 4.3 and higher, documented separately prior to 2002) contains “FIX Session-level Test Cases and Expected Behaviors” and the first section is “When to send a Logout vs. when to just disconnect”:

[quote from spec begin]
In general a Logout message should always be sent prior to shutting down a connection. If the Logout is being sent due to an error condition, the Text field of the Logout should provide a descriptive reason, so that operational support of the remote FIX system can diagnosis the problem. There are exceptions, when it is recommended that a Logout message not be sent, these include:

  • If during a logon either the SenderCompID, TargetCompID or IP address of the session initiator is invalid, it is recommended that the session be immediately terminated and no Logout message sent. This login attempt might be an unauthorized attempt to break into your system; hence one does not want to divulge any information about one’s FIX system, such as: which SenderCompID/TargetCompID values are valid or which version of FIX is supported.
  • 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.
    In all other cases, if sending a Logout does not create risk or violate security, a Logout message should be sent with a descriptive text message.

[quote from spec end]

The “FIX Session-level Test Cases and Expected Behaviors” should be ‘required reading’ for anyone who plans to design and build a FIX engine. Also refer to http://www.fixprotocol.org/specifications/TechDoc-FIXSession

Hi,

I have a question on duplicate login when the session is already
connected (logged in).

How should the session handle when there is a duplicate login in
current session? Should the sequence number increase or should the
application do a session reject for the second attempt?

Or should the first login should also be logged off?

Thanks in advance.

I have not found anything about this in the FIX specs. I guess that
depends on the FIX engine implementation. I did some testing with
QuickFix and it seems to simply ignore the second logon request.

I too think that this depedns on the FIX engine implementation. Some of
the engines that I have worked on discard the second lgin request as a
session-level reject. One of them disconnected even the first session.
So it depends on engine-to-engine.

Vikash