5

我在嵌入式 linux 环境中工作。

它在启动时启动一个 telnet 守护程序，该守护程序监视特定端口并在收到连接时启动程序。

IE

telnetd -l /usr/local/bin/PROGA -p 1234

PROGA - 将不定期输出一些数据。不输出数据时，每隔 X 时间发送一个 'heartbeat' 类型的字符串，让客户端知道我们仍然处于活动状态，即“heartbeat\r\n”

随机时间后，客户端（使用 linux 版本的 telnet，由：启动）telnet xxx.xxx.xxx.xxx 1234)将无法接收到“心跳\r\n”

客户看到的数据：

heartbeat  
heartbeat  
heartbeat  
...
heartbeat
[nothing, should have received heartbeat]
[nothing forever]

发送心跳：

result = printf("%s", heartbeat);

检查结果，它始终是 的长度heartbeat。记录到 syslog 向我们展示了printf()正在以适当的时间间隔成功执行

我已经添加了一个tcdrain和fflush，它们都返回成功，但似乎对这种情况没有帮助。

任何帮助，将不胜感激。

**UDPATE：从服务器端获取了一个wireshark 捕获。很明显，心跳是连续发送的。没有打嗝，没有延迟。不过在客户端上发现了一些有趣的东西。此测试用例中的客户端（Ubuntu 9.04 上的 telnet）似乎突然停止接收心跳（如上所述）。Wireshark 证实了这一点，数据包大停顿。好吧，一旦客户端停止接收心跳，按下任何键击（在客户端上）似乎都会触发客户端缓冲区中的数据喷涌（所有心跳）。客户端上的 Wireshark 也将这些海量数据全部显示在一个数据包中。

不幸的是，我真的不知道这意味着什么。这是线路模式开/关吗？行尾 (\r\n) 非常明显。

**更新 2：运行 netcat 而不是 telnetd，问题不可重现。

4

1 回答 1

1

我要做的第一件事是离开 Wireshark 并尝试找出服务器是否真的在发送消息。在服务器和第三方 PC 上运行 Wireshark 将是有益的。最后一次心跳有什么不同吗？

编辑。嗯，这对你的客户来说是一个有趣的发现。

好像有某种终端的东西在路上。您可能想要使用netcat程序而不是 telnetd。netcat 设计用于在原始模式下通过 TCP 会话发送任意数据，无需任何特殊格式，它能够将任意进程连接到套接字。在 Windows 机器上，您可以在原始模式下使用 PuTTY 来完成同样的事情。

可能仍然值得检查客户端和服务器之间的第三方流量。内核可能正在优化对网络的写入并在内部缓冲数据。这是确保看到的就是网络上实际发生的事情的唯一方法。

于 2010-06-17T08:33:05.330 回答