使用Indy收到的奇怪的罕见乱序数据 [英] Strange rare out-of-order data received using Indy
问题描述
我们在Indy10上遇到了一个奇怪的问题，即我们使用TCP依次发送的两个大字符串（每个数百个字符）出现在另一端奇怪地交织在一起。这样的情况很少发生。
实际发送消息的调用受到IOHandler的writeln方法调用周围关键部分的保护，因此，两个线程不可能同时发送时间。 （我们确定关键部分已实施/正常运行）。这个问题很少发生。症状很奇怪...当我们在字符串A之后发送字符串B时，另一端收到的字符串（在极少数情况下，我们会失败）是字符串A的结尾部分（ ie ，在它的末尾有一个LF），然后是字符串A的前导部分，然后是整个字符串B，然后是单个LF。我们已验证部分读取后， timed out属性是否为true-我们会在每次读取返回内容后记录该属性。另外，我们知道字符串中没有嵌入的LF字符，因为在附加LF并将其发送之前，我们用空格明确替换了字符串中的所有非字母数字字符。
我们在发送和接收端的关键部分内都有日志机制，因此我们可以在线路上看到这种行为。
我们完全感到困惑，并且想知道（尽管总是最低的可能性）是否可能存在一些可能导致此问题的低级Indy问题，例如 eg ，缓冲区以错误的顺序发送...。很难相信这会会成为问题，但我们正在抓住稻草。
有人有什么聪明的主意吗？
在接收端是否有多个线程同时从同一套接字读取数据？即使只是查询Connected（）状态也会导致发生读取。如果您不小心，可能会导致多个线程读取入站数据并将其以随机顺序存储到IOHandler.InputBuffer中。
We're having a bizarre problem with Indy10 where two large strings (a few hundred characters each) that we send out one after the other using TCP are appearing at the other end intertwined oddly. This happens extremely infrequently.
Each string is a complete XML message terminated with a LF and in general the READ process reads an entire XML message, returning when it sees the LF.
The call to actually send the message is protected by a critical section around the call to the IOHandler's writeln method and so it is not possible for two threads to send at the same time. (We're certain the critical section is implemented/working properly). This problem happens very rarely. The symptoms are odd...when we send string A followed by string B what we received at the other end (on the rare occasions where we have failure) is the trailing section of string A by itself (i.e., there's a LF at the end of it) followed by the leading section of string A and then the entire string B followed by a single LF. We've verified that the "timed out" property is not true after the partial read - we log that property after every read that returns content. Also, we know there are no embedded LF characters in the string, as we explicitly replace all non-alphanumeric characters in the string with spaces before appending the LF and sending it.
We have log mechanisms inside the critical sections on both the transmission and receiving ends and so we can see this behavior at the "wire".
We're completely baffled and wondering (although always the lowest possibility) whether there could be some low-level Indy issues that might cause this issue, e.g., buffers being sent in the wrong order....very hard to believe this could be the issue but we're grasping at straws.
Does anyone have any bright ideas?
Do you have multiple threads reading from the same socket at the same time on the receiving end? Even just to query the Connected() status causes a read to occur. That could cause your multiple threads to read the inbound data and store it into the IOHandler.InputBuffer in random order if you are not careful.
这篇关于使用Indy收到的奇怪的罕见乱序数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
