2016-08-01 77 views
1

更新似乎这个问题与Indy并没有像我想象的那样密切相关,而是更多的关于多线程的话题。我会保持这个问题的开放,因为我不是100%相信的。未收到Indy TCP客户端数据

我有一个工作中的应用程序,它与使用Indy TCP客户端的通信伙伴交换ASCII字符串。 通信流程是这样的:

  1. [印等级]发件人发送串
  2. [TCP等级] Wireshark的讲述,这个数据包被发送到收件人
  3. [TCP等级]收件人发送一个TCP ACK确认该分组
  4. [印等级]收件人的IOHandler.ReadLn方法返回数据
  5. [印等级]通过writeLn()逻辑确认被发送到原始发送者

最近我注意到,有一个hickups在通信,使用Wireshark fiddeling后,我得到了下面的图片:

  1. [印等级]发件人发送串
  2. [TCP等级] Wireshark的讲述,这包被传递到接收方
  3. [TCP等级]接收者发送一个TCP ACK,以确认该分组
  4. [印等级]收件人的IOHandler.ReadLn方法并不返回任何哒TA
  5. 无关,因为没有数据可用于收件人

一些超时后,发送者重新发送原单的消息,因为有来自接收方没有逻辑上的确认。

所以我的问题是:如果wireshark告诉我,底层的TCP机制做了他们的工作,Indy客户端怎么可能没有数据可用?

问候, ATTIX

+1

请提供[最小,完整和可验证示例](http://stackoverflow.com/help/mcve)。你所描述的只有在1)你的发送者没有发送行结束符来满足'ReadLn()',或者2)更可能的情况下,你有多个线程同时从同一个Indy IOHandler读取并正在破坏IOHandler.InputBuffer的内容,使得'ReadLn()'无法正确找到行终止符。不要在同一时间从多个线程读取相同的IOHandler。这包括调用“Connected”,它执行内部读取。 –

+0

@RemyLebeau你真棒! 事实上,在读线程之外有一个连接调用了InputBuffer。 删除此调用修复了此问题。我会做更多的测试,并将其标记为适当更新我的帖子。 – Attix

回答

0

[解决] 雷米提供的提示是正确的。 我在呼叫Connected之外的TCP客户端在读取线程之外搞砸了输入缓冲区并导致了不显示的消息症状。

删除(不必要的)检查解决了这个问题。