[This message was posted by Mahesh Kumaraguru of <[email protected]> to the "Transport Independence Framework" discussion forum at http://fixprotocol.org/discuss/49. You can reply to it on-line at http://fixprotocol.org/discuss/read/76b5ef36 - PLEASE DO NOT REPLY BY MAIL.]
FIXProtocol is in application layer which is a layer above TCP, TCP is Transport layer. So the TCP data packet length is not applicable to FIX message length. A single long FIX message could be split into multiple TCP data packets at sender and these data packets assembled back into a FIX message at destination. The 4 byte length in TCP header is the length of TCP packet (TCP header + payload data + TCP trailer). Extract this payload data once you have decoded the packet. The FIX message (or its fragment) is contained in the extracted payload data. Check if the extracted payload data is a complete FIX message, else assemble the FIX message using payloads from subsequent TCP data packet(s). FIX message length tag 9 (Message length, in bytes, forward to the CheckSum field. ALWAYS SECOND FIELD IN MESSAGE. (Always unencrypted)) is of type Length, Length is a sub type of int and there is no mention of the size of int field. > I have read many documents but no mention of the transport data package. > Currently,I use the TCP protocol for transport, to facilitate opening > the package it effectively, I have used 4 byte that contain length of > the FIX Message (Data Package = 4 bytes + FIX Message) So there is not > and FIX have regulations for this ? 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.
