[This message was posted by Shahbaz Chaudhary of [email protected] <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/2a37a713 - PLEASE DO NOT REPLY BY MAIL.]
Thanks, I need to be more careful about newlines! > Actually, if what you are writing is more than just an experiment, you > really can't use a newline as a delimiter even when reading from a file. > Tag 58 could have a newline character in it. There can also be encoded > fields that contain a newline. > > If you encounter a garbled message then one strategy is to look for the > start of the next message by skipping forward until you find the next > "8=FIX.4.4<SOH>9=" (substitute FIX.4.4 with a value appropriate for your > FIX session). > > > I am experimenting with a mini FIX engine. The code I have written so > > far operates on a text file containing a FIX message per line. I > > completely separate messages by using newline as the delimiter. > > Obviously I can't do that for messages which come over the network. > > > > For well-formed messages, I can extract the body length, which will > > tell me how big the message is. What if the body length field is > > missing or out of order? How do I know when the current, garbled > > message ends and a new one starts (this problem is worse if the next > > message is just as garbled). As far as I can tell, there are no end-of- > > message markers in the FIX spec. > > > > How is this normally done? > > > > Thanks [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.
