[This message was posted by joel louis of <[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/0a993f83 - PLEASE DO NOT REPLY BY MAIL.]
Hey Taya, It is clear for me now, thank you ever so much for you all for your assistance. Joel > 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 -~----------~----~----~----~------~----~------~--~---
