tcp - 如何等到您的 TCP 消息被确认

Question

背景:

我们有一个使用持久连接到服务器的客户端/服务器应用程序。

基准测试表明，使用已打开的连接比花费大量时间(2.5 秒)建立新连接(加密)要快很多倍。

不幸的是，旧连接可能已失效。

有没有办法等待发送消息的系统级结果[ACK 或错误]？

等待读取然后到达流的结尾会导致混淆。

我知道消息可能会被分解成数据包。知道消息的任何部分是否被确认或是否全部被确认同样符合我的目的。这里有趣的问题是过时的连接。

Answer 1

Unfortunately, the old connection may be stale.

在这种情况下，您最终会在写入时遇到异常。

Is there a way to wait for the system-level result of sending a message [either ACK or error]?

没有。

Waiting for read and then getting the end of stream causes confusion.

对谁的困惑？处理困惑是代码的工作。如果您收到意外的 EOS，对等方已关闭连接，或者中间防火墙已经关闭，在这种情况下您必须处理它。

I know the message might be broken up into packets.

完全不相关。您无法控制它或它的任何可见性。你得到的是一个被 EOS 或异常终止的字节流。

It would suit my purposes equally well to know either if any part of the message was acked or if all of it was.

不，不会。 ACK 仅表示它已到达对等方的 TCP/IP 堆栈。您的应用程序感兴趣的是它是否已进入对等应用程序，并且只有对等应用程序可以通过应用程序协议(protocol)级别的 ACK 告诉您。 TCP/IP ACK 在这里没有帮助。

The interesting problem here is stale connection.

这是一个相当微不足道的问题。您可以在代码中检测到它，也可以同样处理它。数据库供应商几十年来一直在做这件事。不是火箭科学，也不需要 TCP ACK 的知识。