[This message was posted by Hugo Darley of Fidessa (royalBlue) 
<[email protected]> to the "General Q/A" discussion forum at 
http://fixprotocol.org/discuss/22. You can reply to it on-line at 
http://fixprotocol.org/discuss/read/aaa38999 - PLEASE DO NOT REPLY BY MAIL.]

Hi,

Just a quick question regarding Resend Requests/Sequence resets. I have two 
clients, A and B with flow as follows (sequence numbers in indices):

A sends logon (1)
B sends logoff (1) due to downstream connectivity
A replies to logoff (2)

A sends logon (2)
B replies to logon (2), 369=2
B sends resend request (3), 369=2, 7=1, 16=1
A sends resend request (3), 7=1, 16=0
B sends sequence reset in response (1), 43=Y, 122=<original time>, 369=3, 36=4, 
123=Y
A sends heartbeat (4)
A sends test request (5), 112 is present
B sends heartbeat (4) but does not include 122 value
A sends resend request (5), 369=3, 7=1, 16=1
B sends sequence reset in response (1), 43=Y, no 122 value included, 123=Y, 36=6

A then effectively drops the connection - looking on an internal log shows a 
message at the same time as the final resend request/sequence reset saying:

 'The ResendRequest for Seq #1 is not satisfied by the counterparty,  will not 
process any received message until this missing message transmitted from the 
counterparty.' 

I know the reason fo the dropped connection is due to the behaviour seen but is 
this correct behaviour? I mean, can a client not respond to one resend request 
yet respond to another one a bit later with no adverse effect?

Should party B have dropped the connection sooner?

Many thanks






[You can unsubscribe from this discussion group by sending a message to 
mailto:[email protected]]

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Financial Information eXchange" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/FIX-Protocol?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to