停止并等待文件传输协议，何时停止监听？

Question

我正在开发一个客户端和一个服务器文件传输应用程序，该应用程序带有基于 UDP (SOCK_DGRAM) 的 C++ 套接字。对于 PUT 方法，我有以下执行（握手后）：

client

Send a packet;
if time_out
    send the packet again;
else  //ack received
    send a new packet;

server

wait for the first packet;
send acknowledge;
while(!EOF)
    Get a packet;
    Send an ack;

EOF 基本上是通过与我在握手期间发送的文件大小进行比较来检查我是否收到了整个文件。

在此交换期间，数据包可能随时丢失。客户端可以发送丢失的数据包。它会超时等待 ACK 并重新发送数据包。服务器接收数据包并发送ACK。该 ACK 可能会丢失，此时客户端超时并重新发送他的数据包。由于这些数据包有一个编号序列，我们可以忽略我们多次收到的数据包。

我的困惑发生在文件传输结束时。客户端刚刚发送了包含文件最后几位的数据包。服务器成功接收到它并发送他的ACK。此数据包丢失。服务器应用程序现在位于 while 循环之外，因为他已将最后一位写入文件，并且从他的角度来看，文件传输是成功的。但是，客户端从未收到 ACK，因此超时并重新发送数据包。这里应该发生什么？服务器未在侦听或正在侦听新请求，而不是数据。客户端或服务器应该在什么时候认为传输完成并停止尝试通信？

Answer 1

听起来您正在重新发明TFTP，但客户端和服务器角色倒退了。你确定你需要这样做吗？由于缺少滑动窗口或数据管道，这是一个非常低效的协议。

我看到了 3 个解决您难题的方法：

• 文件传输结束时的三次握手。在收到最后一个数据块后，服务器不仅发送一个 ACK​​，而且等待客户端 ACK ACK。发生这种情况时，服务器知道客户端知道文件传输已完成。如果服务器从未收到 ACK 的 ACK，它会定期重新发送它对最后一个数据块的 ACK。
• 服务器会在文件传输完成后的几分钟内记住已完成的文件传输（或多个 RTT，以较大者为准）。如果在此期间，它从客户端接收到任何应该已经完成​​的文件传输的数据块，则服务器只是确认它而不做任何事情，并重置该文件传输的传输结束计时器。这更复杂，但与以前的解决方案相比具有优势，即服务器能够在文件传输完成后继续执行其他工作。
• 如果服务器接收到任何不属于活动文件传输的数据块，它会以错误（NAK）响应。这适用于它是否是不存在、无效或已经完成的转移的一部分。这是最简单的实现，但也是最丑陋的，因为客户端在收到 NAK 时必须以错误终止。但也许没关系，因为从服务器的角度来看，文件传输仍然是成功的。

Answer 2

显而易见的解决方案是不阻止服务器在之后立即监听。我会让服务器不断发送一个特殊的数据包，其值代表end of file，直到收到来自客户端的确认。

您是否考虑过使用已经实现这种 UDP 文件传输的库，例如 Raknet？这可能会让你的生活更轻松一些，因为你在这里是在重新发明轮子。