|
4.0 Session
< Previous Next >
re: Sequence Number reset after logon
Keith Shangraw / Thomson Financial
6 Jul 1999 10:49AM ETDoh!
I want to apologize if my prior post came across as harsher than it intended. In re-reading Scott Atwell's response to my post, I can see that Scott was disagreeing with my belief that a closed ResendRequest was better than an open-ended one.
I had thought Scott's disagreement was with the FIX-correct value for the NewSeqNum tag! Oops!
In rethinking the situation, I definitely see what Scott is saying with the danger of skipping messages 21-100 in the example I use! So in light of this scenario, I have to agree with Scott and everyone else who recommends that ResendRequests take the form of X to 999999. The cost of bandwidth and the hassle of message duplication is outweighed by the potential business ramifications of lost messages.
But if an engine does make a closed ResendRequest, would it be appropriate to go ahead and Resend all messages (PossDupFlag=Y) from the beginning of the requested GapFill to the most recently sent message? The other engine should just drop the duplicates right? And that way you would be more certain that all messages had been received? It may seem redundant but it would conform to the protocol, right?!?!
Is there any talk of moving to this one and only method of Gap Recovery in future versions of the protocol?
> Hi Scott,
>
> I'm sorry but the protocol actually seems pretty clear in this case. How can the "to be transmitted" on page 15 be interpreted to mean anything other than the outgoing MsgSeqNum value? And if the Initiating FIX engine has sent MsgSeqNum=8 and then performs a GapFill for 1-7, then the next outgoing (to be transmitted) MsgSeqNum must equal "9". You cannot reset the value to "8" because then the other FIX engine will receive TWO messages with MsgSeqNum=8 and shutdown the connection. You can set the value to "10" but why bother? You would just be changing the value of outgoing sequence numbers on your side as well as what they expect. That just puts an empty spot where "9" would have been.
>
> Remember that in Scott Zionic's example, the GapFill was for a specific set of messages.
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>
> In responding to a GapFill Request, I don't see how the protocol could be intrepreted in any way other than I have described. The very fact that the FIX engine transmitted a ResendRequest for a specific set of messages directly implies that THAT FIX engine is HOLDING any message outside that range. In Scott Zionic's example, the requesting engine got MsgSeqNum=8 but only requested 1-7. Since these seven messages were Admins, the responding FIX engine must transmit a SequenceReset-GapFill message to skip these messages. And since the responding engine has already transmitted MsgSeqNum=8, then the MsgSeqNum of the next message it transmits must be "9".
>
> Maybe it would be wiser for any FIX engine to request X-999999, but it is entirely possible that the FIX engine is smart enough to hold MsgSeqNum's 8+ until it receives a satisfactory resolution on 1-7. Meaning that if the Initiating engine fires out messages 8 (Logon) through 100, the accepting engine may be capable of queueing 8-100 until it receives the GapFill for 1-7.
>
> In fact, building a FIX engine capable of handling specific GapFills (as opposed to open-ended GapFills) would cut down on the bandwidth problem. In my example above, only 7 messages would get re-transmitted. Not 100.
>
>
>
> > Keith, I disagree. In your example, you run a very high risk of telling your counterparty to skip messages 10-100 vs. 10-20 on your gap fill and business messages could exist between 20-100. You are assuming that since you think you sent 100 messages your counterparty has received them all and queued them on the side. I, personally, do not think you should attempt to gap fill out of the range (i.e. NewSeqNum > (EndSeqNum + 1) ). I agree with Ryan Pierce's posting that using infinity on the ResendRequest is a superior approach. This warrants further discussion.
> >
> > > On page 15 of the FIX 4.0 spec, in the description of Sequence Reset (Gap Fill) messages it states that...
> > >
> > > "The message is used to reset the value of the next sequence number to be transmitted."
> > >
> > > The "to be transmitted" means that regardless of what messages have been requested in the ResendRequest and regardless of what messages have already been sent, the MsgSeqNum of the NEXT MESSAGE THAT IS SENT will match the value in tag #36 (NewSeqNum).
> > >
> > > So in the scenario described by Scott Zionic, Party A must have a value of "9" in the NewSeqNum field.
> > >
> > > When a ResendRequest is made for a specific set of messages then messages outside that gap must be expected. If a FIX engine receives 1-100 and then requests 10-20, the next message it receives after the gap fill will be 101, not 21. In that case the NewSeqNum value in the SequenceReset-GapFill message will be "101".
> > >
> >
>
re: Sequence Number reset after logon
Keith Shangraw / Thomson Financial 6 Jul 1999 10:49AM ET
|
