2

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

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

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

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

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

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

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

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

4

2 回答 2

0

Using UDB for file transfer is not best idea. There is no way for server or client to know if any packet has been lost so you would only know that during reconstruction assuming you have some mechanism (like counter) to detect lost packes. It would then be hard to request just one of those packets that got lost. And in the end you would have a code that would do what TCP sockets do. So I suggest to start with TCP.

Typical design of a server involves a listener thread that spawns a worker thread whenever there is a new client request. That new thread would handle communication with that particular client and then end. You should keep a limit of clients (threads) that are served simultaneously. Do not spawn a new process for each client - that is inefficient and not needed as this will get you nothing that you can't achieve with threads.

Thread programming requires carefulness so do not cut corners. Otherwise you will have hard time finding and diagnosing problems.

于 2012-04-17T17:43:09.797 回答
0

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

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

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

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

于 2012-04-17T18:00:58.580 回答