如何检查 TCP 发送缓冲区的容量以确保数据传送

我想向我的 TCP 接口添加递送确认。非阻塞写入可以填充发送缓冲区，但如果连接失败，数据可能永远不会到达 - 同时写入已报告数据已接收（通过本地套接字）。

如果我向堆栈添加额外的确认，我可以验证是否收到了每条数据。我认为 ftp 就是这样做的。但我不能借用任何人的代码，并且宁愿不实现确认/重发，特别是因为 TCP 已经完成了大部分工作。

我认为如果我可以在每次 write() 之后验证套接字发送缓冲区是否为空，就可以完成。如果没有更多数据，应该已经全部传送完毕。我不介意清空缓冲区的延迟。

编辑：我意识到 TCP/socket 实现因系统而异，但如果有 Berkeley 或 Linux 解决方案，我可能可以使用。

编辑：为了解决一些建议，我想实现三个级别的 TCP 接口，但我不知道如何完成 *'d 接口。

• 普通 TCP，不保证交付，适用于喜欢危险生活的应用程序。
• *即使数据包从未传递到远程应用程序，也会验证远程主机的接收情况。这降低了我的大部分连接风险（移动客户端），并且可以完全在客户端实现。我认为如果我可以验证套接字传出缓冲区是否为空，就可以实现这一点。
• 应用层 ACK 和重发在 TCP 或 UDP 之上实现，以便验证端点。

实际上在应用程序级别确认内容是唯一的方法。这里有几个问题：

• 当你send数据，即使它离开你的内核，直到你的TCP收到一个ACK关于它。API 不向您提供此信息.

• 您的应用程序收到 ACK 的事实可能意味着：

  • 远程内核（不是应用程序）收到数据。不知道远程进程是否调用recv。也许它在有机会之前就崩溃了recv.
  • 一些代理（许多便宜的设备都这样做）正在与您交谈，并使用与真正的接收者的单独连接。您收到了 ACK，但您不知道远程系统是否有它。如果远程系统有它，请阅读上面的项目符号。

综上所述：

• 您无权访问TCP ACKs
• 即使您可以访问它们，它们也毫无用处

所以你需要一个应用程序级的ACK，但是当然无需重传. The ACK应该只是告诉您“我收到并处理了您的数据”。

EDIT

我看到你坚持你的想法。去寻找SIOCOUTQ如一些 Linux 手册页中所述。当然，它仅适用于 Linux，但看看它是否满足您的需要。