Imported from previous forum
[ original email was from Natan Kugel - nkugel@espeed.com ]
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.
[ original email was from Dennis Wiatzka - dennis.wiatzka@omxgroup.com ]
Sequence Number Reset at Logon is only to ever be used in situations of 24 hour connectivity. The two parties (server and client) must agree upon a time during the 24 hour period at which time one side (again, agreed upon in advance which side will initiate) will initiate the resetting of sequence numbers by sending a Logon message with tag 141 = Y. Prior to sending the reset Logon, the initiator must check for unsent messages by sending a Test Request which should cause any unsent messages.
From the spec:
“One side will initiate the process by sending a TestRequest and wait for a Heartbeat in response to ensure of no sequence number gaps. Once the Heartbeat has been received, the initiator should send a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. The acceptor should respond with a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. At this point new messages from either side should continue with MsgSeqNum of 2. It should be noted that once the initiator sends the Logon with the ResetSeqNumFlag set, the acceptor must obey this request and the message with the last sequence number transmitted “yesterday” may no longer be available.”
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=YPlease confirm the understanding.
[ original email was from Dennis Wiatzka - dennis.wiatzka@omxgroup.com ]
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=YPlease confirm the understanding.
[ original email was from Natan Kugel - nkugel@espeed.com ]
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=YPlease confirm the understanding.
[ original email was from Dennis Wiatzka - dennis.wiatzka@omxgroup.com ]
If 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=YPlease confirm the understanding.