|
5.0 Feedback
< Previous Next >
Re: Sequence number reset / usage of tag 141
Natan Kugel / eSpeed
13 Mar 2008 3:01PM ETIf 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
Natan Kugel / eSpeed 13 Mar 2008 3:01PM ET
|
