[This message was posted by Rolf Andersson of Pantor Engineering <[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/853381ff - PLEASE DO NOT REPLY BY MAIL.]
Clarification: > The decoder must read the message incrementally and do any additional > read operations from the network (normally via a socket read/recv/...) > as needed. unless a blocked stream is used. With a blocked stream you can read a full block by reading the block size and the number of bytes indicated by the block size. /Rolf > Janaka, > > > In FAST 1.0 mention that length of FAST message is send as the initial > > part of the FAST Stream. but that is not mention in FAST 1x1. > > Please refer to the FAST 1x1 spec, section 10 Transfer Encoding I > believe you are referring to a stream of blocks (blocks aren't used in > any of the current live feeds) > > > Then how receiver identifies the length of FAST buffer? > > Short answer: It cannot beforehand. > > The decoder must read the message incrementally and do any additional > read operations from the network (normally via a socket read/recv/...) > as needed. > > This is an implementation issue. > > > Specially in TCP (NOT in UDP) Single message can receive as two or > > more packets. > > > Pls help me. > > Hope this helps, Rolf [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 -~----------~----~----~----~------~----~------~--~---
