mmh, not satisfied with the replies tagged as solution.
The initial post clearly states a problem when sending a message A, which can be corrupted (i.e. shortened) when received (message being synonymous with a single slice of Raw, as is the input of the nodes in question).
I expanded, that parts of message A will be lost on the wire, and sometimes, two distinct messages A and B will even be concatenated into a corrupted one, which seemed related to the fault discovered by the threadstarter.
Elias on the other hand only pointed out, that when sending Message A, B and C those might or might not arrive in order and might or might not arrive in the same frame.
He is addressing the Application Level, where the receiving end might have to reorder and queue stuff, while the original report clearly addresses the Network Level, where the end user is expecting to receive Message A the same way she sent it, which is the cornerstone of TCP being called “reliable”.
Please check tmp’s patch again and play around with it a little. It might take a couple bangs till you see the fault.