多年来，我们的定制软件使用打印机命令语言（PCL）在不同的打印机上打印 .

现在我们有一个新的，轻量级的打印机，我们正在努力支持 . 简单的印刷工作完美无瑕 . 但是，如果打印作业的大小增加，我们会遇到打印作业的中断 .

环境：

  • 之间没有活动网络硬件（如数据包检查防火墙） .

  • 工作站（这是我们的软件运行的地方）在Linux内核版本3.0.101上 . 这里描述的TCP重置正在发生 .

使用Wireshark我们发现了以下内容：

  • 我们看到打印机的TCP接收窗口大小每2-3秒变为零 . 这表明打印机硬件太慢而无法实时处理传入数据 .

  • 这个零窗口超时通常需要大约1-2秒 .

  • 打印机向工作站发送"zero window"确认数据包后，工作站会通过定期发送TCP保持活动数据包来尝试保持与打印机的连接 .

  • 打印机正在回答此保持活动数据包 .

  • 当打印机准备再次处理数据时，它会向工作站发送"TCP Window Update"数据包 . 此数据包包含打印机的新接收窗口大小 . 一旦工作站收到此数据包，它就会再次开始向打印机发送数据 .

这是刚才解释的通信的跟踪片段：
enter image description here

我对“TCP零窗口”机制的理解是，只要打印机正在回答工作站的keepalive数据包，就可以停止和重新启动通信 .

然而，在我们的案例中，通信在一段时间后被中断：
enter image description here

一段时间后（通常在1-3分钟后）工作站不再发送新的保持活动，但正在重置通信 . 对于我们来说，这是不可解释的，因为所有以前的保持活动包直接由打印机确认 .

我也没有成功尝试复制场景 . 我写了一个简单的TCP客户端和服务器 . 为了强制TCP零窗口发生，TCP服务器正在休眠一段时间，而不是继续接收数据 . 但是，无论服务器等待多长时间（睡眠）或中断传输，我都无法让两者中的任何一个重置通信 . 相反，上述TCP keepalive / acknowledge算法在空闲时间运行，保持连接活动 .

您有什么想法让我们的工作站在有效的TCP连接中发送此重置吗？

c sockets printing tcp