Imported from previous forum
Hello,
When Fast used to send FIX message, does FIX session protocol should be used still or all problems have to be resolved using Fast session protocol?
For FIX messages we need to keep SeqNum synchronized, so in case of any problem we have to resend message or increase expected SeqNum value.
How resolved situation when Fast message was lost or broken (so sender’s and receiver’s dictionaries not synchronized and next messages coudn’t be decoded correctly)?
How resend request executed using Fast session protocol?
Thank you.
This is one of the issues under consideration when using FIX over FAST. See section 5 on “Message Recovery” for the current thinking on this issue.
http://www.fixprotocol.org/documents/2786/FIX_over_FAST_Specification_draft.doc
David Rhodes
TransactTools
Hello,
When Fast used to send FIX message, does FIX session protocol should be
used still or all problems have to be resolved using Fast session
protocol? For FIX messages we need to keep SeqNum synchronized, so in
case of any problem we have to resend message or increase expected
SeqNum value.How resolved situation when Fast message was lost or broken (so
sender’s and receiver’s dictionaries not synchronized and next messages
coudn’t be decoded correctly)? How resend request executed using Fast
session protocol?Thank you.
This is one of the issues under consideration when using FIX over
FAST. See section 5 on “Message Recovery” for the current thinking on
this issue.http://www.fixprotocol.org/documents/2786/FIX_over_FAST_Specification-
_draft.doc
Hello,
Thank you for this usefull document.
The “Message Recovery” mechanizm expects the scheduled FastReset message (that have to be sent every N seconds or M messages). Why Receiver doesn’t send FastAlert message with corresponding Error code? In this case Sender will reset outgoing dictionary set and send FastReset message to clear Receiver’s incoming dictionary set? The dictionaries will be synchronized and next messages will be decoded correctly.
With all regards, Sergey.
The idea behind the periodic sending of the FastReset is that it keeps FAST and FIX decoupled. If the FAST layer were to recognize the condition, it would have to know about the FIX checksum. Conversely, if FIX were to send a FAST Alert on a bad checksum, it would have to know it was using FAST versus TCP. Ideally, these are independent layers - FAST can support FIX and other protocols, and FIX can use TCP, FAST or other transports.
That being said, if there is a layer in your architecture that knows both FIX and FAST, sending a FAST Alert and dropping the connection when a bad FIX checksum is detected is a reasonable approach, since it puts you back in the state described in the first case of section 5, where recovery after being disconnected is done.
On your idea of sending a FAST Alert to the other side to indicate that it should then send a FAST Reset, this can get a little tricky since there could be messages in-flight. When we looked at FAST Resets in SCP, we went back and forth on whether there was a way to safely tell the other side that it should reset its outgoing state, and we had a very hard time with it. That’s why we concluded it can really only be up to the sender to decide when to send FAST Resets.
Hope that helps,
- Dave Rhodes
This is one of the issues under consideration when using FIX over
FAST. See section 5 on “Message Recovery” for the current thinking on
this issue.http://www.fixprotocol.org/documents/2786/FIX_over_FAST_Specification-
_draft.docHello,
Thank you for this usefull document.
The “Message Recovery” mechanizm expects the scheduled FastReset message
(that have to be sent every N seconds or M messages). Why Receiver
doesn’t send FastAlert message with corresponding Error code? In this
case Sender will reset outgoing dictionary set and send FastReset
message to clear Receiver’s incoming dictionary set? The dictionaries
will be synchronized and next messages will be decoded correctly.With all regards, Sergey.