Imported from previous forum
Dear all,
I am having a debate with our FIX counterparty and would be extremely grateful for any responses to consideration of the following situation:
PartyA
sends Logon seq 3
PartyB
sends Logon seq 5
PartyA
sends ResendRequest [3,4]
PartyB
sends ExecutionReport seq 3
sends ExecutionReport seq 4
sends SequenceReset-GapFill-PossDup seq 5 [NewSeqNum = 6]
The question is should PartyB send the final SequenceReset at all? My view is that PartyA already has 5, it only asked for [3,4] so that is all it should expect.
In this case PartyA has noticed a gap - it keeps the Logon seq 5 message to re-insert into the stream once it gets [3,4].
In this case it looks to me as though PartyB expects PartyA to ascribe semantics to 2 messages with the same sequence number - i.e. both the Logon and the SequenceReset have seq 5.
I had a conversation with a rep from PartyB and he stated that their view of outbound sequence number processing means that when they resend the final 4 the next sequence number they use MUST be 5, even though they’ve sent it and I haven’t asked for it.
Comments would be very welcome.
Kind regards,
Dave Jepson
Sharepeople Group plc
www.sharepeople.com
[ original email was from Matt Koehler - matt.koehler@transacttools.net ]
> The question is should PartyB send the final SequenceReset at all?
You are supposed to just get what you ask for. If you ask for a resend 3-4, you should get messages 3 and 4.
however, from reading your note, if the counterparty is saying that he can’t do it any other way, then that’s that (is that what you’re saying?)
If the message is a seq reset-gap fill, I would think your engine shouldn’t choke on that. It’s like having a big flashing neon sign saying “IGNORE THIS MESSAGE!” (sort of.)
-Matt Koehler
TransactTools, Inc.
www.transacttools.net
Gap filling @ logon is no different from gap filling in general. For the scenario you describe below I will assume a few points: 1) the resent messages are marked as POSDUPs and 2) all sequence numbers are correct up to the point of the Gap detected on Party A whereby a resend request is issued.
When an engine requests a resend, a few scenarios can occur in which a robust FIX engine should be able to deal with.
FIX engine A issues resend request for n1 to n2:
Scenario1: Engine B issues sequence reset to n2+1 and does not send any POSDUP data. Next msgs from B resume at N2+1.
Scenario2: Engine B sends msgs N1 to N2 all marked as POSDUP. Engine B sends sequence reset to N2+1. Session resumes with new msgs at N2+1.
Scenario3: Engine B sends a combination of POSDUP msgs and multiple sequence resets skipping over all FIX admin messages and or msgs it does not want to resend ( might be order msgs , etc) .
In general, a robust engine should be able to deal with all scenarios. Although a resend request was made, you might not get the resend and you should be able to deal with it. If the counter party is telling your engine to reset sequence #'s I think your implementation should be able to deal with it.
Per the spec, it is ‘legal’ to request just the ‘gap’ or hole in the stream. In practice however many engines don’t support this very well and like it better if the counter party requests from the beginning of the gap forward. ( see 4.0 spec pg 4).
Fix is pretty darn good. Yes, there are areas in which one can get dogmatic about the intent and behavior. My view is… just get it working and don’t break any of the designed in features of the protocol. I have made plenty of interoperability modifications in the interest of getting more orders, quotes and execution reports flowing.
Peter Mellquist
Watcher Technologies
> Dear all,
>
> I am having a debate with our FIX counterparty and would be extremely grateful for any responses to consideration of the following situation:
>
> PartyA
> sends Logon seq 3
>
> PartyB
> sends Logon seq 5
>
> PartyA
> sends ResendRequest [3,4]
>
> PartyB
> sends ExecutionReport seq 3
> sends ExecutionReport seq 4
> sends SequenceReset-GapFill-PossDup seq 5 [NewSeqNum = 6]
>
> The question is should PartyB send the final SequenceReset at all? My view is that PartyA already has 5, it only asked for [3,4] so that is all it should expect.
>
> In this case PartyA has noticed a gap - it keeps the Logon seq 5 message to re-insert into the stream once it gets [3,4].
>
> In this case it looks to me as though PartyB expects PartyA to ascribe semantics to 2 messages with the same sequence number - i.e. both the Logon and the SequenceReset have seq 5.
>
> I had a conversation with a rep from PartyB and he stated that their view of outbound sequence number processing means that when they resend the final 4 the next sequence number they use MUST be 5, even though they’ve sent it and I haven’t asked for it.
>
> Comments would be very welcome.
>
> Kind regards,
> Dave Jepson
> Sharepeople Group plc
> www.sharepeople.com
>
>
>
>
>
>
Peter,
In your scenarios what happens if Engine B has already transmitted up and including M, where M > N2 + 1?
> FIX engine A issues resend request for n1 to n2:
>
> Scenario1: Engine B issues sequence reset to n2+1 and does not send any POSDUP data. Next msgs from B resume at N2+1.
What about the msgs from N2+1 to M? What if Engine A has cleverly kept them to be kind to the network?
If B doesn’t want to retransmit N1 to N2 surely it should send SequenceResetGapFill to M+1 on seqno N1?
> Scenario2: Engine B sends msgs N1 to N2 all marked as POSDUP. Engine B sends sequence reset to N2+1. Session resumes with new msgs at N2+1.
Here, why send the sequence reset at all? Also the same comments about messages up to M.
> Scenario3: Engine B sends a combination of POSDUP msgs and multiple sequence resets skipping over all FIX admin messages and or msgs it does not want to resend ( might be order msgs , etc) .
I agree.
> In general, a robust engine should be able to deal with all scenarios. Although a resend request was made, you might not get the resend and you should be able to deal with it. If the counter party is telling your engine to reset sequence #'s I think your implementation should
be able to deal with it.
>
> Per the spec, it is ‘legal’ to request just the ‘gap’ or hole in the stream. In practice however many engines don’t support this very well and like it better if the counter party requests from the beginning of the gap forward. ( see 4.0 spec pg 4).
Nothing on this page says why asking for N1 to 999999 should be easier to cope with.
I wonder if I am lacking some understanding.
Is there anything missing from the following strategy for handling ResendRequests?
Assume we have already sent up to and including p, and that p >= n >= m.
(1) handle ResendRequest (m, n)
. just resend messages m to n
. next message sent at p+1
(2) handle ResendRequest (m, 999999)
. resend m to p
. next message sent at p+1
In both cases the resent stream could and should use SequenceResetGapFill messages to cover admin messages (or Application msgs if necessary). I can’t understand why a SequenceReset should also be sent to cover n+1, especially on a sequence number already used.
Kind regards,
Dave
A few question about the Scenarios:
Scenario1: Engine B issues sequence reset to n2+1 and does not send any
POSDUP data. Next msgs from B resume at N2+1.
If Engine B have sent Messages After N2 (Say M = N2+1) before it receives the ResendRequest, will Message M be lost due to the fact that next message number we sent has the same SequanceNumber? Or do we also Resend Message M?
Dave,
It seems to me there is a small piece of the puzzle missing that you have not addressed. It would appear to me that in this situation when PartyA recieves sequence number 5 that in thier resend request that message should contain 5 in the resend range or 9999999. Thus prompting your GapFill to re-sequence to 6. You can see an example of this in the "note" under resend request page 15 of the FIX40 spec.
Joshua Opper
The Longview Group
> Dear all,
>
> I am having a debate with our FIX counterparty and would be extremely grateful for any responses to consideration of the following situation:
>
> PartyA
> sends Logon seq 3
>
> PartyB
> sends Logon seq 5
>
> PartyA
> sends ResendRequest [3,4]
>
> PartyB
> sends ExecutionReport seq 3
> sends ExecutionReport seq 4
> sends SequenceReset-GapFill-PossDup seq 5 [NewSeqNum = 6]
>
> The question is should PartyB send the final SequenceReset at all? My view is that PartyA already has 5, it only asked for [3,4] so that is all it should expect.
>
> In this case PartyA has noticed a gap - it keeps the Logon seq 5 message to re-insert into the stream once it gets [3,4].
>
> In this case it looks to me as though PartyB expects PartyA to ascribe semantics to 2 messages with the same sequence number - i.e. both the Logon and the SequenceReset have seq 5.
>
> I had a conversation with a rep from PartyB and he stated that their view of outbound sequence number processing means that when they resend the final 4 the next sequence number they use MUST be 5, even though they’ve sent it and I haven’t asked for it.
>
> Comments would be very welcome.
>
> Kind regards,
> Dave Jepson
> Sharepeople Group plc
> www.sharepeople.com
>
>
>
>
>
>
Joshua,
Please read the section ‘Ordered Message Processing’ starting at the bottom of page 4.
This section states clearly the 2 policies available:
a) a network friendly option where only the missing messages are requested, and
b) the option where all messages subsequent to the first missing messages are requested.
The resend policy I have pursued is the former, as my original post shows.
The example you cite appears misleading and contradicts the statements on page 4, since it indicates that messages 8-9 should be ignored. This advice would in fact correspond to policy (b) outlined above, however the example doesn’t go so far as to state that EndSeqNo should be 999999.
Kind regards,
Dave
> Dave,
>
> It seems to me there is a small piece of the puzzle missing that you have not addressed. It would appear to me that in this situation when PartyA recieves sequence number 5 that in thier resend request that message should contain 5 in the resend range or 9999999. Thus prompting your GapFill to re-sequence to 6. You can see an example of this in the “note” under resend request page 15 of the FIX40 spec.
>
> Joshua Opper
> The Longview Group
>
>
>
> > Dear all,
> >
> > I am having a debate with our FIX counterparty and would be extremely grateful for any responses to consideration of the following situation:
> >
> > PartyA
> > sends Logon seq 3
> >
> > PartyB
> > sends Logon seq 5
> >
> > PartyA
> > sends ResendRequest [3,4]
> >
> > PartyB
> > sends ExecutionReport seq 3
> > sends ExecutionReport seq 4
> > sends SequenceReset-GapFill-PossDup seq 5 [NewSeqNum = 6]
> >
> > The question is should PartyB send the final SequenceReset at all? My view is that PartyA already has 5, it only asked for [3,4] so that is all it should expect.
> >
> > In this case PartyA has noticed a gap - it keeps the Logon seq 5 message to re-insert into the stream once it gets [3,4].
> >
> > In this case it looks to me as though PartyB expects PartyA to ascribe semantics to 2 messages with the same sequence number - i.e. both the Logon and the SequenceReset have seq 5.
> >
> > I had a conversation with a rep from PartyB and he stated that their view of outbound sequence number processing means that when they resend the final 4 the next sequence number they use MUST be 5, even though they’ve sent it and I haven’t asked for it.
> >
> > Comments would be very welcome.
> >
> > Kind regards,
> > Dave Jepson
> > Sharepeople Group plc
> > www.sharepeople.com
> >
> >
> >
> >
> >
> >
>