Imported from previous forum
Hello,
I am very new to FIX protocol, please bare with me. We suspect there is some issue between us and remote server, so I put up a sniffer to capature data. I noticed that when data being transmit across wire, it will look like this.
frame 1(size 1 byte): only contain information begins with 8=FIX 4.1…etc
frame 2: rest of actual data.
I have checked out fix-41-with_errata_19990630.pdf, on page 60 of 109. It says “Identifies beginning of new message and protocol version. ALWAYS FIRST FIELD IN MESSAGE. (Always unencrypted)”, however, it doesn’t state that will be a ‘individual frame/packet’. It almost make me think that somewhere in the application is sending a flush()/fflush() simliar type of command to close down first frame, then begin to fill actual data into 2nd frame.
Is this normal behavior? If so, what’s the reason behind it? Perhaps someone can point me to right direction where I should be look up the reason behind this. I was told by our developers they weren’t doing such thing within the code.
Thank you
Hello,
I am very new to FIX protocol, please bare with me. We suspect there is
some issue between us and remote server, so I put up a sniffer to
capature data. I noticed that when data being transmit across wire, it
will look like this. frame 1(size 1 byte): only contain information
begins with 8=FIX 4.1…etc frame 2: rest of actual data.I have checked out fix-41-with_errata_19990630.pdf, on page 60 of 109.
It says “Identifies beginning of new message and protocol version.
ALWAYS FIRST FIELD IN MESSAGE. (Always unencrypted)”, however, it
doesn’t state that will be a ‘individual frame/packet’. It almost make
me think that somewhere in the application is sending a flush()/fflush()
simliar type of command to close down first frame, then begin to fill
actual data into 2nd frame.Is this normal behavior? If so, what’s the reason behind it? Perhaps
someone can point me to right direction where I should be look up the
reason behind this. I was told by our developers they weren’t doing such
thing within the code.Thank you
This is normal behavior. If a FIX message is incomplete (not terminated with 10=XXX) due to a packet size issue, you’ll have to wait for the next TCP/IP packet and append the received data to the leftovers from the previous packet. It is possible that the incomplete message is also due to an error, but you won’t know that until you receive the next packet.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
I agree with what has been posted. A FIX message split into multiple TCP packets is perfectly normal behavior.
TCP is a stream-oriented protocol, not a message-oriented protocol. It sends a reliable, ordered stream of data from one party to another, but there are no guarantees regarding message boundaries.
There’s no guaranteed correlation between calls to write buffers to a socket and how the operating system chooses to divide it up into TCP packets that go over the wire. Similarly, on the receiving end, calls to read from a socket have no guaranteed correlation between the calls the other computer made to write the data. TCP just guarantees reliable delivery of a stream of data; how it is divided into blocks to go over the wire is outside the control of the trading applications. However, this shouldn’t matter to a well-written FIX engine; the FIX Protocol defines the beginning and end of a message, so a FIX engine can split an incoming stream into messages, regardless of how they are divided into packets. If a message fragment is received by the engine, that’s simply kept around, and subsequent socket reads will append to it until there’s a completed message that can be passed up to the application layer.