Imported from previous forum
[ original email was from Akis Tzortzis - at@jesqa.com ]
Hello
I am writing a FIX client. During Logon the server "remembers" me and expects a particular message sequence number. But the Logon message has a ResetSeqNumFlag which is supposed to allow sequence message resynching. Am I reading the specs properly? The server I am connecting to seems to be ignoring this flag. If the message number I send it during Logon is less than what it expects, it logs me out immediately (no further chance of negotiation).
Thanks in anticipation
Akis Tzortzis
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
Akis,
In the FIX 4.3 spec, vol 2 p 8, there’s a description of when and how to use ResetSeqNumFlag. In brief it’s meant to be used beteen consenting counterparties at a particular time of day over 24-hour sessions to clarify start-of-day. During the course of the business day a Login with ResetSeqNumFlag set to Y should be treated as an error. And except for the start-of-day event you are never allowed to assign a sequence number lower than previously sent, even on Logon.
The way to resync a FIX session at Logon is to recognize an incoming sequence number higher than expected and use ResendRequest to fill the gap.
> Hello
>
> I am writing a FIX client. During Logon the server "remembers" me and expects a particular message sequence number. But the Logon message has a ResetSeqNumFlag which is supposed to allow sequence message resynching. Am I reading the specs properly? The server I am connecting to seems to be ignoring this flag. If the message number I send it during Logon is less than what it expects, it logs me out immediately (no further chance of negotiation).
>
> Thanks in anticipation
>
> Akis Tzortzis
>
[ original email was from Akis Tzortzis - at@jesqa.com ]
Mine is on page 7 
I somehow get the feeling that the protocol still tries to arrange connectivity between two private firms - but in fact it’s being used for connectivity between a server and multiple clients.
So we are halfway through the day and our trader’s machine dies, losing all state. We manage to revive the machine and try to connect to the FIX server. Where will I get the message sequence number from in order to even go through “Logon”? Various kludges come to mind, eg “invent a very big number, the server will accept your connection and request a resend, fill them up with a gap fill”. Until the next crash.
Surely there must be a more professional solution to this?
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
First I’d hope you design your client such that the disaster scenario you describe will not be part of standard operating procedure. Never. Okay, hardly ever. Then the standard way this is treated in prime time is for support personnel at the server and client sites to communicate by phone, exchange sequence numbers and recovery states, agree to manual intervention and setup the client to logon using the next sequence number expected by the server.
> Mine is on page 7
>
> I somehow get the feeling that the protocol still tries to arrange connectivity between two private firms - but in fact it’s being used for connectivity between a server and multiple clients.
>
> So we are halfway through the day and our trader’s machine dies, losing all state. We manage to revive the machine and try to connect to the FIX server. Where will I get the message sequence number from in order to even go through “Logon”? Various kludges come to mind, eg “invent a very big number, the server will accept your connection and request a resend, fill them up with a gap fill”. Until the next crash.
>
> Surely there must be a more professional solution to this?
>
>
[ original email was from Akis Tzortzis - at@jesqa.com ]
That approach will not work in the "one server - thousands of clients, all connecting and disconnecting during a trading day" scenario. If FIX is to work for derivatives exchanges or other setups where one server will support thousands of clients then it needs to change a bit.
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
“One server - thousands of clients” is the model we’re all working with. Persistence of session sequence numbers across logons is not an optional feature of the FIX Protocol - it is absolutely required. If a particular client fails regularly in this regard - either during certification or after going live - the firm running the “one server” should isolate it from the network until the problem is remedied.
> That approach will not work in the "one server - thousands of clients, all connecting and disconnecting during a trading day" scenario. If FIX is to work for derivatives exchanges or other setups where one server will support thousands of clients then it needs to change a bit.
>
>
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
The persistence of the sequence number across connections (a session can span multiple sequential connections to the same counterparty (TargetCompID)) is the basic foundation of FIX. The previous Actant engine had this capability provided. If there is a catastrophic loss - i.e. loss of entire platform and persistence it is usually handled as a manual procedure with the counterparty to reset or retrieve the sequence number. The use of an initial logon after the start or resumption of connection is never used to reset the sequence number.
> “One server - thousands of clients” is the model we’re all working with. Persistence of session sequence numbers across logons is not an optional feature of the FIX Protocol - it is absolutely required. If a particular client fails regularly in this regard - either during certification or after going live - the firm running the “one server” should isolate it from the network until the problem is remedied.
>
> > That approach will not work in the “one server - thousands of clients, all connecting and disconnecting during a trading day” scenario. If FIX is to work for derivatives exchanges or other setups where one server will support thousands of clients then it needs to change a bit.
> >
> >
>
[ original email was from Akis Tzortzis - at@jesqa.com ]
If the sequence number is not correct then the server refuses the connection, it denies the chance for negotiation. I would understand this being the case for errors in the user name and password, which do not change frequently and can be recovered from other sources, but to apply such harsh rules to a counter which changes so often and the user has no idea about?
What is there to be gained by this sequence number ritual during a new logon? I do not mean to be disrespectful of a protocol that has been going on for a decade, I am just a bit puzzled. I can see no value in insisting that a new connection has to carry on from where an older one left off in terms of a useless sequence number. I say useless because for the duration of the logout you don’t care, and when you eventually log back on you re-request all open positions and the last thing you want is to re-send to the server “stale” instructions, eg orders and quotes. So even if there is a sequence number mismatch at logon and even if the server requests a resend, noone would send it old orders and quotes, they would just gap-fill them. So why bother at all (during logon)?
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
The purpose of having a persistant sequence number and continuing it across physical sessions is to provide an opportunity to recover data missed during an outage. If your client crashes while the server is sending an Execution Report, then at logon the client will recognize the gap and request resend of just the message dropped. Similary your client may be sending an Allocation instruction when the server crashes. When the server recovers and your client logs on again the lost Allocation will be requested based on the gap. There are message that you wouldn’t bother or want to resend, but on recovery you have an opportunity to make a rational decision on the fate of each dropped item.
> If the sequence number is not correct then the server refuses the connection, it denies the chance for negotiation. I would understand this being the case for errors in the user name and password, which do not change frequently and can be recovered from other sources, but to apply such harsh rules to a counter which changes so often and the user has no idea about?
>
> What is there to be gained by this sequence number ritual during a new logon? I do not mean to be disrespectful of a protocol that has been going on for a decade, I am just a bit puzzled. I can see no value in insisting that a new connection has to carry on from where an older one left off in terms of a useless sequence number. I say useless because for the duration of the logout you don’t care, and when you eventually log back on you re-request all open positions and the last thing you want is to re-send to the server “stale” instructions, eg orders and quotes. So even if there is a sequence number mismatch at logon and even if the server requests a resend, noone would send it old orders and quotes, they would just gap-fill them. So why bother at all (during logon)?
>
[ original email was from Akis Tzortzis - at@jesqa.com ]
I should perhaps have been more clear in my original message and explain that I am writing a client to a derivatives exchange server ( which has a FIX engine mounted on top of its traditional server ).
During a connection, the client always gets a fresh picture from the server - it does not store or carry over any data from previous connections. A typical connection phase looks like this: connect, send mass hold, get product list, get outstanding manual orders, get day trades, subscribe to prices and executions.
This would only need to be changed in cases where the server does not support a particular type of request, or where such a request would be prohibitively expensive.