Strange rare data out of order obtained with Indy

Question

We have a strange problem with Indy10, where two large lines (several hundred characters each) that we send one after another using TCP appear on the other end, weirdly intertwined. This is extremely rare.

Each line is a complete XML message completed by LF, and in general, the READ process reads the whole XML message, returning when it sees LF.

The call to actually send the message is protected by the critical section around the call to the IOHandler writeln method, and therefore it is not possible to send two streams at the same time. (We are sure that the critical section is implemented / working correctly). This problem is very rare. The symptoms are odd ... when we send line A, followed by line B, which we received at the other end (in rare cases, when we have a failure), is the final part of line A by itself (i.e. there LF at the end of it), followed by the leading section of row A, and then the entire row of B, followed by a single LF. We checked that the "timed out" property is not true after a partial read - we register this property after each read that returns the contents. In addition, we know that there are no built-in LF characters in the string, since we explicitly replace all non-alphanumeric characters in the string with spaces before adding LF and sending it.

We have log mechanisms inside critical sections at both ends of the transmit and receive, and therefore we can see this behavior on the “wire”.

We are completely baffled and wonder (although it is always the lowest opportunity) if there can be some low-level Indy problems that can cause this problem, for example, buffers are sent in the wrong order ... it is very difficult to believe this may be a problem, but we grab the straw.

Does anyone have any bright ideas?

Answer 1

Do you have multiple threads read from the same socket at the same time on the receiving side? Even to request the status of Connected (), reads occur. This can cause your multiple threads to read incoming data and store them in IOHandler.InputBuffer in random order, if you are not careful.

Answer 2

You can try Wireshark to find out how the data is transmitted. This way you can find out if there is a problem on the server or on the client. Also, remember to use TCP to get the "guaranteed" reliable data in the correct order.

Answer 3

Are you using TCP or UDP? If you use UDP, it is possible (and expected) that UDP packets can be received in a different order than they were transmitted due to network routing. If so, you need to add some kind of packet identifier to each UDP packet so that the recipient can properly sort the packets.

Answer 4

Have you checked the Nagle settings for IOHandler? We had a similar problem that we fixed by setting UseNagle to false. In our case, sending and receiving large amounts of data in packets was slow due to Nagley merging, so it is not quite the same as your situation.