|
FAST Protocol
< Previous Next >
Re: FAST Over TCP
Rolf Andersson / Pantor Engineering
26 Jan 2010 6:13PM ET Hi Fernando,
sorry, I don't remember the details of the EBS feed and I don't have their specification at hand. I suggest you check directly with their data feed support.
The problem of decoding FAST messages sent over a TCP transport was discussed at length way back when we were working with 1.1. Depending on your implementation, you may benefit from blocks.
/Rolf
> 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
FAST Over TCP Fernando Jeronymo / Societe Generale 26 Jan 2010 5:49PM ET Re: FAST Over TCP
Rolf Andersson / Pantor Engineering 26 Jan 2010 6:13PM ET
|
