c - 有没有办法告诉操作系统丢弃任何缓冲的传出 TCP 数据？

Question

我在基于 TCP 的客户端软件中遇到了一个有趣/烦人的情况，它是这样的:

1. 我的客户端进程在笔记本电脑上运行，它通过 TCP 连接到我的服务器进程(在局域网中的另一台机器上运行)
2. 不负责任的用户在客户端传输 TCP 数据时将以太网电缆从他的笔记本电脑中拔出
3. 客户端进程继续使用一些额外的 TCP 数据调用 send()，填充操作系统的 SO_SNDBUF 缓冲区，直到...
4. 客户端进程收到以太网接口(interface)已关闭的通知(通过 MacOS/X 的 SCDynamicStoreCallback 功能)，并通过在其 TCP 套接字上调用 close() 进行响应
5. 两到五秒过去了...
6. 用户重新插入以太网电缆
7. 客户端进程收到接口(interface)已备份的通知，并自动重新连接到服务器

一切都很好......除了通常还有一个不需要的第 8 步，它是这样的:

.8。在步骤 4 中关闭()的 TCP 套接字恢复(!)并发送该套接字的内核出站数据缓冲区中的剩余数据。发生这种情况是因为操作系统在释放套接字之前尝试传送所有出站 TCP 数据……通常是一件好事，但在这种情况下，我希望这种情况不会发生。

那么，问题是，有没有办法告诉 TCP 层丢弃其 SO_SNDBUF 中的数据？如果是这样，我可以在步骤 4 中关闭()之前调用死套接字，并且我不必担心在旧套接字被放弃后来自旧套接字的僵尸数据到达服务器。

Answer 1

这(从两个不同的 TCP 连接接收到的数据相对于彼此没有排序)是 TCP/IP 的基本属性。您不应该尝试通过清除发送缓冲区来解决它 - 这是脆弱的。相反，您应该修复应用程序以在应用程序层处理这种可能性。

例如，如果您在服务器端收到一个您认为已经连接的客户端的新连接，您可能应该断开现有连接。

此外，该过程的第 4 步有点可疑。实际上，您应该等到 TCP 报告错误(或连接上发生应用程序级超时)——正如您所注意到的，如果物理断开只是短暂的断开，TCP 将恢复。