Imported from previous forum
If in response to resend request, we receive messages which yesterday’s date in Tag 122. Should the Session layer reject all these messages, or honour them?
[ original email was from John Prewett - jprewett@lavatrading.com ]
Hi Menita,
The FIX session layer has no standardized responsibilities concerning reception of delayed messages, thus the answer to your question is that a standard FIX session layer should receive them and pass them to the application layer.
Your application requirements should dictate whether a delayed message is considered to be "too late". Therefore only your application should be responsible for issuing a Reject as needed.
If you have FIX sessions that continue to run as the clock moves from 23:59:59 to 00:00:01 you could easily receive messages that are "from yesterday" and yet not delayed. Watch out for time zone issues too. The SendingTime and OrigSendingTime tags are in GMT. Thus yesterday could potentially happen in the afternoon (local time), depending on where you reside.
Some execution venues offer a delayed order protection system, whereby a received order that is received more than ‘n’ seconds late will be rejected. Again, this is done on the application level and is dependent upon the time difference between when the message is received and when the message was sent (SendingTime) or re-sent (OrigSendingTime). Thus this doesn’t necessarily check the sending date, just the elapsed time between when it was sent and when it was received.
I hope this helps.
> If in response to resend request, we receive messages which yesterday’s date in Tag 122. Should the Session layer reject all these messages, or honour them?
>
FIX uses Tag 122 to indicate the original sending time of the message. It maybe, due to communication loss between the parties or other similar circumstances, the messages are lost between the counterparties. Under such circumstances resends are generated on restoration of the connection. The OrigSendingTime tag in that case contains the time stamp for the original message and not the one which was resent. But in case where such information is not being stored by the engine implementation, you can do with the current time which is same as the SendingTime Tag.
The original sending time tag is mostly used on a business level to gauge whether an order expiry or the like has occurred or not. It can no way be used to make any FIX session level decisions. Therefore, it can only be used to generate business/application level rejects rather than any session level ones.
In most of the FIX 4.0 implementations I have had the experience of, the message queues are flushed at the end of a day at a time that has been mutually agreed upon by the counterparties. As such there is little question of OrigSendingTime being carried over multiple days. To cut things short, there is no constraint on the FIX session level interpretation of the tag other than the fact that is must be equal to or less than the SendingTime tag.
Kashif Awan,
kashif.awan@kolachi.net.
Manager Electronic Connectivity,
Kolachi Advanced Technologies.
www.kolachi.com.
> If in response to resend request, we receive messages which yesterday’s date in Tag 122. Should the Session layer reject all these messages, or honour them?
>