[This message was posted by Sri Thayaparan of Millennium IT <[email protected]> to the "4.2 Changes" discussion forum at http://fixprotocol.org/discuss/5. You can reply to it on-line at http://fixprotocol.org/discuss/read/d1ba89e1 - PLEASE DO NOT REPLY BY MAIL.]
Joel, I feel you are confused. Let me simplyfy this. The rule is :- 1. If sequence number is less than expected, send logout and drop the connection immediately 2. If sequence number is greater than expected, send a resend request to the peer and synchronize. In the example in hand, it is the second situation that prevails. Acceptor has sent a resend request with start seq = 4 and end sequence = 63. This means, the acceptor has got only upto sequence number 4 and thus expecting 5, whereas 64 was received. The behaviour of the acceptor, in this case is fine. The acceptor has sent the resend with an end-of sequence by deriving it from the logon sequence of the initiator (Logon sequence - 1). This has the same effect as requesting from 4 to 0. Regards, Thaya. > > Thanks Taya, > > in other word if the sequence is higher or less than expected the > accepto will logout? > > Joel > > > Joel, > > > > In your scenario, the fact that the acceptor has sent a resend > > request, means that the acceptor is behind the sender (sender has > > higher sequence). The format for resend requests do vary in FIX 4.2. > > The formats are :- > > > > 1. From m to N (Gap request) 2. From m to 0 (From m upto last > > sent msg) > > > > Both these messages mean that the receiver is behind the sender or has > > a gap. Here (unusually) the acceptor sends out a "Gap request" (which > > also is technically valid as the login sequence was 64, and the > > acceptor needs msgs from 4 to 63). Easiest is to use the 2nd form. > > > > The interpretation is, the acceptor has received messages successfully > > only upto 4 and then has received from 64 (including 64). In the > > resend request, tag 63 denotes the end sequence and need not > > necessarily mean that end-sequence + 1 th message has been received > > successfully. > > > > > > If sender is behind (lets say the login came with sequence number 2), > > the the acceptor shoul immediately logout and drop the connection. > > > > Hope this cleared your query. > > > > Rgds, Thaya. > > > > > Hi Guys, > > > > > > I am a bit confused too here, I have 2 questions > > > > > > 1) We have Acceptor: 35=2, 34=5,43=N, 7=4, 16=63 > > > > > > Why would acceptor send Resend Request with endof sequence 63. So if > > > I understood 63 is the last seq acceptor has received or not? > > > > > > 2) This for a seq less than expected Acceptor loggout and what would > > > happened then if it was higher than expected? > > > > > > Thank you in advance, > > > > > > Joel > > > > Hello all, > > > > > > > > I got a question regarding the Sequence Reset message in protocol > > > > 4.2. The following is the scenario: > > > > > > > Initiator: 35=A, 34=64 Acceptor: 35=A, 34=4, 43=N Acceptor: 35=2, > > > 34=5,43=N, 7=4, 16=63 Initiator: 35=4, 34=4, 43=Y, 36=64, 123=Y > > > Acceptor:35=0, 34=6, 43=N Initiator: 35=0, 34=64 Acceptor: 35=5, > > > 34=7, 43=N, 58= Error: Incoming sequence number (64) is less than > > > expected > > > (65) without PossDupFlag being set. Logging out. > > > > > > > > Please let me know what correct behavior of Initator/Acceptor > > > > according to FIX4.2 in this case is. > > > > > > > > Thank you [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 -~----------~----~----~----~------~----~------~--~---
