python - 使用 tcp 重传的可靠 udp

Question

关闭。这个问题需要details or clarity .它目前不接受答案。












想改进这个问题？通过 editing this post 添加详细信息并澄清问题.

2年前关闭。




Improve this question




我是发件人服务器发送的 UDP 多播数据(证券交易所数据)的客户端接收者。我连续接收 udp 多播数据包流，顺序编号为 1 到大约 35,000,000，在 6 小时内均匀发送。我需要确保在每次说〜256个数据包之后定期处理一组N个数据包之前接收到所有数据包，直到N个数据包。即我需要可靠的 UDP。

使用 TCP 重传来模拟可靠的 UDP。如果任何 udp 数据包丢失/未收到，则使用 tcp 协议(protocol)通过指定所需的丢失数据包范围(起始编号、结束编号)来请求它。
发送方记录迄今为止通过 UDP 多播发送的所有数据包(证券交易所数据)。因此，发送方将仅通过 TCP 重新发送接收方通过 TCP 专门请求的那些数据包编号。这就是接收方实现 UDP 可靠性的方式。 UDP 丢包率非常小(小于 0.001%)，除非在中午开始 UDP 组播，在这种情况下，之前从 1 发送到某个 N 的所有 UDP 数据包都需要在 TCP 上重新发送，而实时传输正在接收编号为 N+1 的 UDP 多播数据包。)我无法请求发件人(证券交易所)更改其协议(protocol)——它已修复。

在 CPU 方面实现这一点的有效算法是什么？
问题是速度BigOh。我可以使用几个嵌套循环和方法制作一个简单的算法，但它不一定是最好的。

我正在考虑维护一个数字 N，它确认我已收到 UDP
数据包 1 到 N，以及任何数据包编号。 M 不是下一个预期的包号。 N+1 将被缓冲，例如 256 个数据包，然后 TCP 将用于请求丢失的数字。然后正常的 UDP 接收从 TCP 请求完成后最后确认接收的号码开始恢复。

例子:
假设接收方接收到的 UDP 数据包顺序如下 {1,2,3,6,7,8,9,10 ...}
在第 3 号数据包之后，下一个数据包是第 6 号数据包。数据包 4 到 5 丢失。
因此使用 TCP 请求({4 到 5})请求丢失的数据包 {4,5}，并缓冲 {6,7,8,9,10}。 10GBaseT LAN 卡上有足够的空间来缓冲 35,000,000 个数据包。
所以:接收 UDP {1,2,3}，通过 TCP 请求重新填充 {4,5}，继续接收 UDP {6,7,8,9,10, ...}

Answer 1

我假设由于您正在使用多播，因此该数据将有多个接收者？ (因为如果不是，您可能会改用单播)

因此，如果接收者可以选择请求 TCP 重新传输他们没有收到的数据包，这意味着发送程序需要在内存中保留最近发送的 UDP 数据包的拷贝，以便当它接收到一个retransmit-request，它将具有可用于重传的请求数据。假设您使用唯一 ID 标记每个数据包，它可以将此数据存储在 std::map 中。或 std::unordered_map或类似的快速查找。

真正的问题是，发射机应该保留多少旧数据包数据？理想情况下，它会保留所有这些，因为您永远不知道给定的接收者可能错过了多少并且可能想要请求；但这需要无限的内存，所以这不是一个现实的选择。可能你能做的最好的事情就是决定你愿意为此目的占用多少 RAM，并记录你表中的字节总数，当它达到限制时，开始丢弃最旧的数据包从表中取出，以使其大小保持在限制范围内。

我写了一个 open-source library它基本上使用您描述的技术(多播 UDP + TCP-retransmit-to-recover-from-packet-loss)尽快跨多个主机同步数据库；我在实现它时学到的一些东西包括:

如果/如果可以的话，将您的数据消息打包成更大的数据包，直到您传输的网络的 MTU(例如 IPv4/以太网的 1388 字节)。非常小的数据包大小(如 48 字节/数据包)效率低下，因为固定大小的数据包 header 占发送/接收的总数据的更大百分比。

仅在您的发送套接字指示它已准备好写入时尝试发送。 (即不要假设你永远不会填满套接字的输出数据缓冲区；如果你的流量是“突发的”，你可能会在某个时候)

通过使您的 UDP 套接字的发送和接收缓冲区尽可能大，最大限度地减少 UDP 数据包丢失

通过在专用的高优先级线程中进行所有 UDP 接收来进一步最小化 UDP 数据包丢失(然后可以将接收到的 UDP 数据路由回普通优先级线程以进行进一步处理——主要是避免允许接收 UDP -socket 的传入数据缓冲区如果可能溢出)

对于 TCP 重传部分，请记住，在最坏的情况下，TCP 流可能会减慢到几乎每秒字节数为零，这使得确保客户端 A 的较差 TCP 性能不会阻塞 TCP 通信非常重要与客户端 B、C、D 等之间的往来。这可以通过非阻塞 I/O 和 select() 来完成。 (或 poll() 或类似)，或异步网络，或通过多线程；避免阻塞 I/O，除非你正在实现一个线程每套接字模型(并且可能也避免该模型，因为无限期阻塞的内部接收()线程很难干净地关闭)

想想在什么情况下(如果有的话)客户端永远不会收到特定的数据包是可以接受的；有没有可以的情况？或者整个系统是否必须停止运行，直到每个接收者都接收到组中的每个数据包，而不管这可能需要多长时间？

如果你想变得真正花哨，你可以看看Forward Error Correction跨数据包对数据进行编码的算法，这样即使接收方从未收到(最多一定百分比)数据包，它仍然可以解码所有数据。这使得需要重新传输请求的可能性降低，代价是使所有数据包稍微变大。