|
5.0 Feedback
< Previous Next >
Re: Sequence number reset / usage of tag 141
Dennis Wiatzka / OMX <>
13 Mar 2008 3:20PM ETIf it is a new business day then no need to use a Logon reset (sequence should start back at 1).
If it is the same business day, you should log in first and then use a Logon reset after ensuring there are no missing messages.
Again, this feature of the FIX spec should only be used in cases of 24 hour connectivity though as long as a session has been established and messages have all been accounted for it is safe to use the Logon reset.
All other uses tend to be to work arounds for programming problems which should instead be solved rather than papered over through the use of a Logon reset.
It does not sound as though the situation you are describing is for 24 hours connectivity. It sounds as though you are trying to deal with a reconnection problem where the sequence numbers are out.
Many people try to use the Logon reset when one side has lost messages it had already sent with sequence numbers higher than what that side will be subsequently trying to logon with. This results in the other side rejecting the logon because the sequence was less than expected. The problem is that the use of a Logon reset to get around this scenario creates opportunities to lose messages. Don't fall into that trap.
Instead the side that is losing messages should fix its bug rather than trying to use the Logon reset.
Cheers, Dennis
> If no messages from the previous session have been expected, the client
> can reset sequence numbers and log on using tag 141=Y, is not it? This
> will trigger server resetting the sequence numbers. In this case, how
> loose is the requriment of established session? I thank you in advance.
>
> > Oh, and one more thing - the key to all this is that the Logon with
> > reset is only ever to be sent when there is already an active session.
> > This affords the two sides the opportunity to ensure there is no
> > message loss before the Logon reset takes place.
> >
> > I hope that addresses the specifics of your question.
> >
> > Cheers, Dennis
> >
> > > Dear all: This is related to tag 141 available in 4.3. If the client
> > > drives sequence number reset, connects as well as logs on using
> > > sequence number 1 | tag 141=Y, the server will reset sequence
> > > numbers and will replu with logon | tag 141=Y.
> > >
> > > If the server drives sequence number reset, is the only option (A)
> > > for the server to wait for the client to connect and log on with
> > > next sequence number (tag 141=N or absent), exchange the heart beats
> > > and send another logon seq. num 1 | tag 141=Y and wait for response
> > > from client?
> > >
> > > Could the server, (B) replay to logon seq num = next | tag 141=N or
> > > absent with logon seq num 1 | tag 141=Y. This would reduce time it
> > > takes for resynch and sequence number reset, if driven by server.
> > >
> > > It seems option A follows FIX specs verbatim. Question 1) Is option
> > > B a valid option? 2) If Yes, then the server should not generate
> > > resend requests as result of client's first logon (prior to sequence
> > > number reset).
> > > 3) If Yes, the client then would need to send another logon with
> > > sequence number 1 | tag 141=Y
> > >
> > > Please confirm the understanding.
Re: Sequence number reset / usage of tag 141
Dennis Wiatzka / OMX 13 Mar 2008 3:20PM ET
|
