[This message was posted by Fernando Jeronymo of Societe Generale <[email protected]> to the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply to it on-line at http://fixprotocol.org/discuss/read/5e6484d9 - PLEASE DO NOT REPLY BY MAIL.]
Hi Rolf, As per FAST 1x1 Section 10, we would have "BLOCK SIZE (1000 bytes) | MSG | ... | MSG | X (byte 1001)" Now the question is, regarding EBS, I am not sure they are doing that... What we seem to receive (and as per their documentation) we have: "MSG | MSG | MSG | ... | MSG" without the block. As per EBS spec (EBS Live FastFIX version 6.3.pdf): 3.4 FAST/FIX Considerations The FAST/FIX message will consist of a sequence of individual messages, not blocks of messages. Can you or someone else confirm that EBS does not send blocks? I just am unsure on how to decode FIX over FAST over TCP if they are not within a block... right now we try to decode, error, wait for more data, try to decode, error, until I can successfully decode a message. Regards, --Fernando > Hi Fernando, > > please have a look at section 10 of the FAST specification. You can use > blocks to enable reading a whole message before starting to decode the > message. You can also put more than one (complete) message into a block. > > Let me know if you have any further questions. > > /Rolf > > > > Hi All, > > > > What is the proposed way of correctly parsing a TCP FAST encoded > > message? (FIX over FAST)? > > > > If we are in FIX world, I have: "8=FIX.M.N^A9=...^A10=123^A" > > > > So I can easily search for "8=FIX...^A" and "^A10=NNN^A", and here I > > have my SOM (Start of Message) and EOM (End of Message) > > > > The issue is, this gets encoded over FAST and sent on TCP... then we > > retrieve a FAST encoded message but we don't have any way to know when > > we should start FAST decoding. At this point we try to decode, if the > > message is incomplete I generate an error and wait for more data and > > then when I receive more data I try to decode again. > > > > Ideally I would have some kind of framing (not FAST encoded) that > > tells me how many bytes I should expect, or gives me the Begin/End of > > the message, so I can read everything from the socket first to then > > decode later. > > > > Is this something that has been discussed already? If there are some > > guidelines please share them with me, so I can then forward them to > > the market in question :) > > > > Best Regards, --Fernando [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
