multithreading - 基于 UDP 套接字的无速率文件传输

Question

我是套接字编程的新手，我需要实现一个基于 UDP 的无速率文件传输系统来验证我研究中的方案。这是我需要做的:

我希望服务器 S 向一组对等点 A、B、C 等发送文件。该文件分为多个数据包。一开始，peers 会向服务器发送一个 Request 消息来初始化传输。每当 S 收到来自客户端的请求时，它都会无速率地将编码数据包(如何编码由我的设计完成，编码本身具有纠删能力，这就是为什么我可以通过 UDP 无速率传输)到该客户端。客户端不断收集数据包并尝试对其进行解码。当它最终解码所有数据包并成功重建文件时，它会向服务器发送一个停止消息，并且 S 将停止向该客户端传输。

对等方异步请求文件(他们可能在不同时间请求文件)。服务器必须能够同时为多个对等点提供服务。不同客户端的编码数据包是不同的(尽管它们都是从相同的源数据包编码的)。

这是我对实现的看法。不过，我在 unix 网络编程方面没有太多经验，所以我想知道您是否可以帮助我评估它，看看它是否可行或有效。

我要将服务器实现为具有两个套接字端口的并发 UDP 服务器(根据 UNP 书，类似于 TFTP)。一种是接收控制消息，就像在我的上下文中它用于请求和停止消息一样。服务器将为每个请求维护一个标志(最初=1)。当它收到来自客户端的停止消息时，该标志将被设置为 0。

当服务接收到请求时，它将 fork() 一个新进程，该进程使用第二个套接字和端口将编码的数据包发送到客户端。只要标志为1，服务器就一直向客户端发送数据包。当它变为0时，发送结束。

客户端程序很容易做到。只需发送一个请求，recvfrom() 服务器，逐步解码文件并在最后发送一个停止消息。

这种设计可行吗？我主要担心的是:(1)通过 fork 多个进程是否有效？或者我应该使用线程？ (2)、如果我必须使用多个进程，子进程如何知道标志位？感谢您的意见。

Answer 1

使用 UDB 进行文件传输并不是最好的主意。服务器或客户端无法知道是否有任何数据包丢失，因此您只能在重建期间假设您有某种机制(如计数器)来检测丢失的数据包。这样就很难只请求其中一个丢失的数据包。最后，您将拥有一个可以执行 TCP 套接字功能的代码。所以我建议从TCP开始。

服务器的典型设计涉及一个监听器线程，只要有新的客户端请求，它就会产生一个工作线程。该新线程将处理与该特定客户端的通信，然后结束。您应该限制同时服务的客户端(线程)。不要为每个客户端生成一个新进程 - 这是低效且不需要的，因为这不会为您带来任何线程无法实现的东西。

线程编程需要小心，所以不要偷工减料。否则，您将很难发现和诊断问题。