Imported from previous forum
[ original email was from Ranjit M - ranjit_unni@yahoo.com ]
Hi,
The FIX 4.2 header documentation for OrigSendingTime (tag #122) is:
"Required for message resent as a result of a ResendRequest. If data is not available set to same value as SendingTime."
My question is related to this:
Should a Sequence Reset message have the OrigSendingTime tag set?
One can read the above mentioned documentation in two ways(at least):
-
Since a Sequence Reset message is always sent in response to a ResendRequest, it satisfies the first requirement. Hence the OrigSendingTime tag must always be set.
-
Since a Sequence Reset message is never “resent” it doesn’t make sense to send the OrigSendingTime. (But the second part of the documentation says even if you dont have this data-which you dont in this case-set it to the same value as SendingTime which kind of makes this decision tough)
Please tell me which of the above (or any other) is the correct way to read it.
Thanks in advance,
Ranjit
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Should a Sequence Reset message have the OrigSendingTime tag set?
My feeling is that OrigSendingTime shouldn’t be required on a SeqReset. While a SeqReset is sent in response to a Resend Request, it is not resent in response to a Resend Request. Given that the requirement for OrigSendingTime is conditional on the message being resent in response to a Resend Request, I don’t believe the condition applies.
From a practical standpoint, I can’t see any valid business meaning for OrigSendingTime on a SeqReset. With an application message or a Reject (the only session-level message that can be resent), OrigSendingTime has a clear meaning and is useful, since it allows the other party to quantify the amount of “staleness.” But a SeqReset skips over one or more messages sent over a range of time. What OrigSendingTime makes sense for a SeqReset? The oldest time in the range? The newest time? The median? The average?
I interpret the part about setting OrigSendingTime to SendingTime as applying in a system which for some reason could recover the business content of a message but not the sending time, or worse, was never designed to store the sending time.
Now failing to specify OrigSendingTime might cause incompatibilities. The FIX session-level test cases indicate an error if PossDupFlag is set (which is required on the SeqReset) but OrigSendingTime is absent.
Given that a literal reading of the spec supports not requiring OrigSendingTime on SeqResets, and there’s no business purpose for it, I believe the test case should be changed.
[ original email was from Ranjit M - ranjit_unni@yahoo.com ]
>Now failing to specify OrigSendingTime might cause incompatibilities. The FIX session-level test cases indicate an error if PossDupFlag is set (which is required on the SeqReset) but OrigSendingTime is absent.
>
This is exactly my predicament. Whether to consider this behaviour as an incompatibility and address it through non-standard means or to consider this as normal behaviour and change the behaviour of the session implementation. I guess these kind of issues will occur and there is no immediate solution.
> Given that a literal reading of the spec supports not requiring OrigSendingTime on SeqResets, and there’s no business purpose for it, I believe the test case should be changed.
>
Is there some process for getting this testcase changed in the forthcoming 4.4 release?
[ original email was from Oren Miller - omiller@thoughtworks.com ]
I’m thinking the problem is not with OrigSendingTime. I think the confusion is actually caused by PossDup.
I believe that if PossDup does exist, that OrigSendingTime should be present if PossDup really implies that the message may be a duplicate.
The core of the issue here I think is that a sequence reset cannot be a duplicate, so why is it marked as such? If you are going to remove OrigSendingTime from SequenceReset, I think it just indicates that PossDup=Y has no business being there either. Get rid of the PossDup, and OrigSendingTime goes away as well.
> > Should a Sequence Reset message have the OrigSendingTime tag set?
>
> My feeling is that OrigSendingTime shouldn’t be required on a SeqReset. While a SeqReset is sent in response to a Resend Request, it is not resent in response to a Resend Request. Given that the requirement for OrigSendingTime is conditional on the message being resent in response to a Resend Request, I don’t believe the condition applies.
>
> From a practical standpoint, I can’t see any valid business meaning for OrigSendingTime on a SeqReset. With an application message or a Reject (the only session-level message that can be resent), OrigSendingTime has a clear meaning and is useful, since it allows the other party to quantify the amount of “staleness.” But a SeqReset skips over one or more messages sent over a range of time. What OrigSendingTime makes sense for a SeqReset? The oldest time in the range? The newest time? The median? The average?
>
> I interpret the part about setting OrigSendingTime to SendingTime as applying in a system which for some reason could recover the business content of a message but not the sending time, or worse, was never designed to store the sending time.
>
> Now failing to specify OrigSendingTime might cause incompatibilities. The FIX session-level test cases indicate an error if PossDupFlag is set (which is required on the SeqReset) but OrigSendingTime is absent.
>
> Given that a literal reading of the spec supports not requiring OrigSendingTime on SeqResets, and there’s no business purpose for it, I believe the test case should be changed.
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I’m thinking the problem is not with OrigSendingTime. I think the confusion is actually caused by PossDup.
>
> I believe that if PossDup does exist, that OrigSendingTime should be present if PossDup really implies that the message may be a duplicate.
>
> The core of the issue here I think is that a sequence reset cannot be a duplicate, so why is it marked as such? If you are going to remove OrigSendingTime from SequenceReset, I think it just indicates that PossDup=Y has no business being there either. Get rid of the PossDup, and OrigSendingTime goes away as well.
I believe there’s a really good reason why the PossDup belongs on the SeqReset, especially the SeqReset-Gap Fill.
There’s a certain “gotcha” case that happens quite regularly when two firms are both out of sync with each other.
Firm A sends:
100 Logon
101 Order
Firm B is expecting 90, and so sends:
200 Logon
201 Resend Request 90-0 (in response to 100)
202 Resend Request 90-0 (in response to 101)
Firm A is expecting 190, and so sends:
102 Resend Request 190-0 (in response to 200)
90 PD Gap Fill to 103 (in response to 201)
103 Resend Request 190-0 (in response to 201)
90 PD Gap Fill to 104 (in response to 202)
104 Resend Request 190-0 (in response to 202)
Firm B sees 102, processes it and sends a Resend Request, sees 90 and advances the sequence number to 103, sees 103 and responds to the resend request.
Now the critical point comes. That second gap fill has a sequence number of 90. Were it not PossDup, Firm B would see the sequence number decreasing (expecting 104, sees 90). At that point, Firm B would kick off Firm A for lowering the sequence number. But because 90 IS PossDup, Firm B realizes that it is less than expected, so ignores it. 104 then comes along, and everything is fine.
There’s a symmetry here. When responding to a Resend Request, it makes sense that everything sent in response should be PossDup because the sequence number itself is possibly duplicated. (And if multiple Resend Request’s have been sent, it’s definitely duplicated.)
[ original email was from Oren Miller - omiller@thoughtworks.com ]
I see your point here. This also clarifies what you were saying earlier about what OrigSendingTime represents (ambiguously) in this instance.
We’ve always been using the same value as SendingTime which I believe is the all around safest thing to do. It seems like it also would be a good policy to ignore the OrigSendingTime when accepting a SequenceReset. (hence your desire to change the test case)
> > I’m thinking the problem is not with OrigSendingTime. I think the confusion is actually caused by PossDup.
> >
> > I believe that if PossDup does exist, that OrigSendingTime should be present if PossDup really implies that the message may be a duplicate.
> >
> > The core of the issue here I think is that a sequence reset cannot be a duplicate, so why is it marked as such? If you are going to remove OrigSendingTime from SequenceReset, I think it just indicates that PossDup=Y has no business being there either. Get rid of the PossDup, and OrigSendingTime goes away as well.
>
> I believe there’s a really good reason why the PossDup belongs on the SeqReset, especially the SeqReset-Gap Fill.
>
> There’s a certain “gotcha” case that happens quite regularly when two firms are both out of sync with each other.
>
> Firm A sends:
>
> 100 Logon
> 101 Order
>
> Firm B is expecting 90, and so sends:
>
> 200 Logon
> 201 Resend Request 90-0 (in response to 100)
> 202 Resend Request 90-0 (in response to 101)
>
> Firm A is expecting 190, and so sends:
>
> 102 Resend Request 190-0 (in response to 200)
> 90 PD Gap Fill to 103 (in response to 201)
> 103 Resend Request 190-0 (in response to 201)
> 90 PD Gap Fill to 104 (in response to 202)
> 104 Resend Request 190-0 (in response to 202)
>
> Firm B sees 102, processes it and sends a Resend Request, sees 90 and advances the sequence number to 103, sees 103 and responds to the resend request.
>
> Now the critical point comes. That second gap fill has a sequence number of 90. Were it not PossDup, Firm B would see the sequence number decreasing (expecting 104, sees 90). At that point, Firm B would kick off Firm A for lowering the sequence number. But because 90 IS PossDup, Firm B realizes that it is less than expected, so ignores it. 104 then comes along, and everything is fine.
>
> There’s a symmetry here. When responding to a Resend Request, it makes sense that everything sent in response should be PossDup because the sequence number itself is possibly duplicated. (And if multiple Resend Request’s have been sent, it’s definitely duplicated.)
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> We’ve always been using the same value as SendingTime which I believe is the all around safest thing to do.
You’re speaking in terms of SeqReset’s only, I presume, and not doing this on resent application messages?
[ original email was from Oren Miller - omiller@thoughtworks.com ]
:), yes. I was refering to the topic under discussion being sequence resets. For all other messages we use the standard rule.
> > We’ve always been using the same value as SendingTime which I believe is the all around safest thing to do.
>
> You’re speaking in terms of SeqReset’s only, I presume, and not doing this on resent application messages?
>
>