基于 UDP 套接字的无速率文件传输答案

【问题标题】：a UDP socket based rateless file transmission基于 UDP 套接字的无速率文件传输
【发布时间】：2012-04-29 01:55:33
【问题描述】：

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

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

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

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

我要将服务器实现为具有两个套接字端口的并发 UDP 服务器（根据 UNP 手册，类似于 TFTP）。一种是接收控制消息，就像在我的上下文中它用于请求和停止消息一样。服务器将为每个请求维护一个标志（最初=1）。当它收到来自客户端的停止消息时，该标志将被设置为 0。
当服务接收到请求时，它将 fork() 一个新进程，该进程使用第二个套接字和端口将编码的数据包发送到客户端。只要标志位为1，服务器就一直向客户端发送数据包。当它变为0时，发送结束。
客户端程序很容易做到。只需发送请求，recvfrom() 服务端，逐步解码文件，最后发送停止消息。

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

【问题讨论】：

你使用什么编程语言？

标签： multithreading sockets process udp

【解决方案1】：

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

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

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

【讨论】：

我的编码方案有一种纠删能力，所以不需要重传。其原理是，对于n个源包，任何接收到的n个或略多于n个的编码包都能够成功恢复n个源包。代表这一思想的一个优秀代码称为 LT（Luby-Transform）代码。有了这个特性，使用 UDP 可以节省协议开销和握手时间。但是，解码会很耗时，这就是为什么我想检查实现，看看在协议开销和解码时间之间进行权衡是否值得。
顺便说一句，当产生一个新线程与客户端通信时，我必须在该线程中生成另一个套接字并为该客户端使用一个新端口，对吧？跨度>
是的，您需要新的套接字来与每个客户端进行通信。使用 UDP，您可以使用相同的套接字，但由于每个客户端都会有新线程，您应该为每个线程创建新的套接字。
只是一个小问题，当它请求传输时使用客户端的 sockaddr_in 结构是否可以（当服务器在侦听器线程中执行 recvfrom() 时由内核返回）与新套接字在工作线程中？如果这个问题很愚蠢，我很抱歉。感谢您的帮助。
另一个想法，也许我可以只维护两个套接字一个不同的端口。一个给听众，另一个给工人。侦听器套接字仅用于接收（控制消息，基本上是请求和停止）。服务器将维护一个请求的客户端地址列表。工作套接字仅用于发送。所以只需要 2 个套接字和 2 个线程，对吗？每当接收到控制消息时，都会使用互斥锁来修改客户端信息，以便可以通知工作线程（添加新客户端或删除它）。这种设计合理吗？衷心感谢。

【解决方案2】：

使用 UDP 传输文件会很有趣:(

每个消息的结构/类应该包含一个序列号和一个校验和。这应该使每个客户端能够在传输结束时检测并请求重新传输任何丢失的块。

在本地 LAN 上，UDP 可能是一个巨大的赢家。您可以一次将整个文件通过 UDP 广播到所有客户端，然后在最后依次询问每个客户端它缺少哪些块并仅发送这些块。我希望卡巴斯基等能够使用这样的方案来更新我所有的本地盒子。

我在 CANBUS 网络上使用了这种广播方案，其中有几十个微控制器需要下载新图像。软件升级需要几分钟而不是几小时。

【讨论】：