UDP传输过快，Apache Mina无法处理

Question

UDP传输过快，Apache Mina无法处理

c++socketsudpmina

4

我们决定使用UDP协议在客户端[C++]（使用poll）和服务器[JAVA] [Apache MINA]之间发送像坐标这样的大量数据。

为了尽可能避免传输过程中的分段，每个数据报最大只有512字节。我添加了一个带有ID的头部，以便可以监控接收到的数据报数量和哪些数据报已经被接收。

问题在于我们发送数据报的速度太快了。首先接收一些数据报然后就出现了大量的丢失，然后再接收一些又会丢失很多。我们接收到的ID数据报序列类似于[1]，[2]，[250]，[251]......

这个问题也会发生在本地环境中（仅使用localhost一个网络卡）。我并不关心丢失的数据报，但这里不是简单的网络丢失问题，这对我来说很难处理。

我的问题是：

- 在客户端上，如何获取最佳设置或套接字设置？ - 如何以最大限度地发送数据而不过多地发送？ - 在服务器端，Apache MINA似乎表示它自己管理“套接字缓冲区的大小”，但是还有一些需要关注的设置吗？ - 如果我们的连接已经允许我们下载常规文件时至少具有这种带宽，请问是否可以达到大约1MB/s的速度？ - 现在，当我们想要传输大约4KB的坐标信息时，我们必须添加睡眠时间，以便等待5分钟或更长时间才能完成传输。对于我们来说，这是一个很大的问题，因为我们应该每分钟至少发送10MB的坐标信息。

- itMaxence

1

我会先安装Wireshark来确认数据包是否到达了设备。同时，我也会尝试调整操作系统的UDP缓冲区大小。虽然mina处理速度较慢，但操作系统应该会进行缓存，所以这听起来有些可疑。 - MK.

3

为了传输大约4KB的坐标信息，我们不得不添加等待时间，以便等待5分钟或更长时间。这意味着每40秒只能传输一个数据包...... 转用电报和莫尔斯电码可能会更快。 - ElderBug

2

看起来像是拥塞问题，所以您需要一些拥塞控制，或者至少限制发送速度。但是5分钟内只有4KB的数据传输量似乎表明问题更大，可能出现在您的代码中。 - ElderBug

1

@SChepurin：“我的应用程序占用了1TB的硬盘空间，但实际上不应该这样”，你的回答是：“买一个2TB的硬盘”。这并不是解决方案。 - ElderBug

1

@ElderBug - 你看到结尾的“检查”了吗？这只是一个测试，而不是解决方案（没有代码的解决方案能提供什么建议呢？）。 - SChepurin

显示剩余4条评论

2个回答

-1

当任意数量的数据报可以丢失而不会牺牲QoS时，UDP才是可行的选择。我不熟悉Apache MINA，但所描述的场景类似于按顺序处理每个数据报的服务器。在这种情况下，正在服务的一个数据报到达时，所有到达的数据报都将丢失 - 没有UDP数据报的排队。就像我说的那样，我不知道MINA是否可以调整为并行数据报处理，但如果不能，则选择工具是错误的。

- SergeyA

我相对肯定你关于这个的错误。操作系统将排队接收到的UDP数据包。 - MK.

由于UDP数据报最大可以达到64KB，系统缓冲区几乎保证可以容纳128个512字节的数据包。即使是有缺陷的应用程序，也很难以这种方式丢失数据包。 - ElderBug

这是我亲眼所见，所以我坚持这个观点。 - SergeyA

1

*NIX通常会将数据包排队到固定大小的缓冲区中，_然后默默地丢弃无法适应缓冲区的数据包_。发送方没有反向压力或限制。因此，@MK.正确指出了数据包被排队，而SergeyA则正确指出了数据包被丢弃。我不知道其他操作系统可能会做什么。 - Useless

就如所写的那样，这纯粹是胡说八道。处理一个单独的UDP数据包会导致所有后续数据包的丢失？！处理从来不会引起这种情况。只有缓冲区溢出才会导致这种情况，但自从Linux 2.6（很久以前）起，这些缓冲区大小为4 MB = 8192个512字节的数据包。 - MSalters

显示剩余2条评论

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Useless · Accepted Answer

如果您想要可靠的传输，应该使用TCP。这将让您以几乎与网络和客户端中更慢的速度相同的速度发送数据，而且不会有数据丢失。

如果您想要高度优化的低延迟传输，而且不需要保证可靠性，您需要使用UDP。这将让您以网络处理数据的最快速度发送数据，但您也可以发送得更快，或者比客户端读取数据的速度更快，然后就会丢包。

如果您想要可靠的高度优化的低延迟传输，并具有精细的控制，您必须在UDP之上实现TCP的自定义子集。这听起来您可能无法或不应该这样做。

通常通过实验来找到最佳设置或套接字设置。

如果您丢包的原因是因为客户端很慢，那么您需要让客户端变得更快。更大的接收缓冲区只能购买一定量的预留空间（例如吸收突发数据），但是如果您系统地较慢，则任何合理大小的缓冲区最终都会填满。

请注意，这仅可以治疗过度或可以避免的丢失。即使您的客户端可以跟上进程，各种网络堆栈层（即使不离开单个计算机）也可以丢失数据包，因此如果没有自定义重传逻辑，您仍然不能将其视为可靠（我们又回到了实现TCP）。

您需要一些来自接收方的确认/否认/反压缩/拥塞/任何消息，以便从源发送尽可能多的数据。这正是TCP免费提供给您的东西，并且自己良好地实现它相对较为棘手。

我刚刚看到通过loopback使用scp时的速度达到了8MB/s，所以我会说是的。这使用了TCP，显然选择了AES128来动态加密和解密文件--如果您只是发送纯文本数据，则应该轻松获得同等的性能。