【问题标题】:Missed Socket Message丢失的套接字消息
【发布时间】:2009-06-18 04:18:10
【问题描述】:

我从事套接字编程已经很多年了,但我从来没有使用 TCP 丢失过消息——直到现在。我在 C 语言中有一个 java 服务器和一个客户端 - 都在本地主机上。他们以字符串的形式来回发送短消息,中间有一些延迟。我有一个特殊情况,消息永远不会到达客户端。它是可重现的,但奇怪的是依赖于机器。

为了提供更多细节,我可以调试服务器端并查看发送和刷新。我可以附加到客户端并遍历选择调用(在循环中),但它根本不会出现。有没有人遇到过这种情况,除了编码错误还有其他解释吗?

换句话说,如果您有一个已连接的套接字并在一侧进行写入并在另一侧进行读取,那么中间会发生什么导致这样的事情?

另一个细节 - 我在环回接口上使用了 tcpdump,可以看到丢失的消息。

【问题讨论】:

  • 您的客户端是多线程的吗?是否有可能在该消息上也有一个单独的线程正在选择()?另外,您使用的是什么操作系统?
  • 我认为其他线程不可能选择它。这是在 Linux 上。好主意 - 我用柜台验证了。

标签: java c sockets


【解决方案1】:

我以前在 SMTP 事务中看到过这种情况。您在那台机器上运行了病毒扫描程序吗?如果是这样,请尝试将其关闭,看看是否有影响。

否则,我建议安装Wireshark,以便您查看实际发生的情况。

【讨论】:

  • 他使用 tcpdump 并看到了丢失的消息。 Wireshark 提供了更多细节,但不会产生太大影响。
【解决方案2】:

最后 - 在嗅了一些之后,我发现了问题。在读取之前发送了两条消息(有时,但很少......),因此它们都被读取,但只处理了第一条。这就是为什么第二条消息似乎从未到达的原因。它被埋在接收缓冲区中。

【讨论】:

  • qrdl 提出了一个很好的观点。 UDP 保证 1 次写入 == 1 次读取,但 TCP 明确不保证(以实现更好的吞吐量)。
  • 关于流控制的好点 - 这是防止这种错误的好方法,但是根据我的经验调用 bs 是粗鲁的。我几乎没有发布答案,因为正是这个原因,这是一个如此愚蠢的错误,但我想给其他看到这个的人一个想法。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2018-04-02
  • 1970-01-01
  • 2014-02-28
  • 1970-01-01
  • 1970-01-01
  • 2014-08-23
  • 2016-09-15
相关资源
最近更新 更多