Imported from previous forum
I had to fail a process and a subsequent logon was with a low sequence number. The other side of the session responded with a logout (35=5) informing me of this. My application (acting a client) continued to send logon messages until the desired sequence number was reached.
Most fix engines I’ve dealt with will then accept the logon and a session can be established. In this case the server side of the session does not even acknowledge the login messages, even after the sequence number has gone far beyond the expected number. Even after restarting my application (with an acceptably high sequence number, even leaving the app down for 20 minutes) I fail to get a response from the other side.
Should this be acceptable behavior on the part of the server side? The other (server) side in this case is an external vendor, so I cannot intervene on that side of the communication.
I’m wondering if it might have to do with lower level socket connectivity, or if it a choice on the programmer’s side, or if it is a deficiency in the FIX implementation.
It is possible that the counterparty (server) you are connecting to may have a limit to the number of unsuccessful logon attempts on a particular connection (which you may have exceeded in attempting to increment the sequence number to its appropriate value). This is generally implemented to prevent the unauthorized access of a trading session; you may not receive a response from the server on subsequent logons as it may not want to consume a sequence number until the session has been manually verified. Not having specific details of how the server functions, this is merely an educated assumption. Your best option given the situation is to contact the counterparty to rectify the situation.
-KD
I had to fail a process and a subsequent logon was with a low sequence
number. The other side of the session responded with a logout (35=5)
informing me of this. My application (acting a client) continued to send
logon messages until the desired sequence number was reached.Most fix engines I’ve dealt with will then accept the logon and a
session can be established. In this case the server side of the session
does not even acknowledge the login messages, even after the sequence
number has gone far beyond the expected number. Even after restarting my
application (with an acceptably high sequence number, even leaving the
app down for 20 minutes) I fail to get a response from the other side.Should this be acceptable behavior on the part of the server side? The
other (server) side in this case is an external vendor, so I cannot
intervene on that side of the communication.I’m wondering if it might have to do with lower level socket
connectivity, or if it a choice on the programmer’s side, or if it is a
deficiency in the FIX implementation.