UDP传输太快，Apache Mina不处理
UDP transfer is too fast, Apache Mina doesn't handle it
我们决定使用 UDP 发送大量数据，例如坐标：
- 客户端 [C++]（使用轮询）
- 服务器 [JAVA] [Apache MINA]
我的数据报最大只有 512 字节，以尽可能避免传输过程中的碎片。
每个数据报都有一个我添加的头（里面有一个ID），这样我就可以监控:
- 收到了多少数据报
- 收到了哪些
问题是我们发送数据报的速度太快了。我们像第一个一样收到，然后损失很大，然后又得到一些，再次损失惨重。接收到的 ID 数据报序列类似于 [1]、[2]、[250]、[251].....
本地也有这个问题（使用localhost，只有1个网卡）
我不关心丢失数据报，但这里不是简单的网络丢失（我可以处理）
所以我的问题是：
- 在客户端，我怎样才能得到最好的：
- 设置，还是套接字设置？
- 如何尽可能多地发送而不是太多？
- 在服务器上，Apache MINA 似乎说它自己管理 ~"size of the buffer socket"~ 但是还有一些设置需要关心吗？
- 是否有可能达到 1MB/s 之类的速度，因为我们的连接已经允许我们在下载常规文件时至少拥有此带宽？
现在，当我们想要传输 ~4KB 的坐标信息时，我们必须添加睡眠时间，以便我们等待 5 分钟或更长时间才能完成，这对我们来说是一个大问题，知道我们应该发送每分钟至少10MB坐标信息。
只有在不牺牲 QoS 的情况下可以丢失任意数量的数据报时，UDP 才是可行的选择。我不熟悉 Apache MINA，但所描述的场景类似于按顺序处理每个数据报的服务器。在这种情况下，所有在服务时到达的数据报都将丢失 - 没有 UDP 数据报排队。就像我说的，我不知道 MINA 是否可以针对并行数据报处理进行调整，但如果不能，那只是工具选择错误。
如果你想要可靠的传输，你应该使用 TCP。这将使您的发送速度几乎与较慢的网络和客户端一样快，没有任何损失。
如果您想要高度优化的低延迟传输，不需要可靠，您需要 UDP。这将使您发送的速度与网络可以处理的一样快，但您也可以发送得更快，或者比客户端读取的速度更快，然后您就会丢失数据包。
如果您想要具有细粒度控制的可靠的高度优化的低延迟传输，您将最终在 UDP 之上实现 TCP 的自定义子集。听起来你不能或不应该这样做。
... how can I get the best settings, or socket settings
通常通过实验。
如果丢失数据包的原因是客户端速度慢，则需要使客户端更快。较大的接收缓冲区只能购买固定数量的净空（比如吸收突发），但如果你系统地变慢，任何理智大小的缓冲区最终都会填满。
但是请注意，这只能解决过度或可避免的掉落问题。即使您的客户端可以跟上，各种网络堆栈层（即使不留下一个盒子）也允许丢弃数据包，因此如果没有自定义重传逻辑，您仍然不能将其视为可靠（我们又回到实现 TCP） .
... way to send as much as I can without being to much?
您需要某种 ack/nack/back-pressure/throttling/congestion/whatever 消息从接收者返回到源。这正是 TCP 免费提供给您的东西，您自己实现起来相对棘手。
Is it possible to reach something like 1MB/s ...
我刚刚看到 8MB/s 使用 scp over loopback，所以我会说 是的。它使用 TCP 并且显然选择了 AES128 来动态加密和解密文件 - 如果您只是发送明文，获得同等性能应该是微不足道的。
我们决定使用 UDP 发送大量数据，例如坐标：
- 客户端 [C++]（使用轮询）
- 服务器 [JAVA] [Apache MINA]
我的数据报最大只有 512 字节，以尽可能避免传输过程中的碎片。
每个数据报都有一个我添加的头（里面有一个ID），这样我就可以监控:
- 收到了多少数据报
- 收到了哪些
问题是我们发送数据报的速度太快了。我们像第一个一样收到，然后损失很大，然后又得到一些，再次损失惨重。接收到的 ID 数据报序列类似于 [1]、[2]、[250]、[251].....
本地也有这个问题（使用localhost，只有1个网卡） 我不关心丢失数据报，但这里不是简单的网络丢失（我可以处理）
所以我的问题是：
- 在客户端，我怎样才能得到最好的：
- 设置，还是套接字设置？
- 如何尽可能多地发送而不是太多？
- 在服务器上，Apache MINA 似乎说它自己管理 ~"size of the buffer socket"~ 但是还有一些设置需要关心吗？
- 是否有可能达到 1MB/s 之类的速度，因为我们的连接已经允许我们在下载常规文件时至少拥有此带宽？
现在，当我们想要传输 ~4KB 的坐标信息时，我们必须添加睡眠时间，以便我们等待 5 分钟或更长时间才能完成，这对我们来说是一个大问题，知道我们应该发送每分钟至少10MB坐标信息。
只有在不牺牲 QoS 的情况下可以丢失任意数量的数据报时，UDP 才是可行的选择。我不熟悉 Apache MINA，但所描述的场景类似于按顺序处理每个数据报的服务器。在这种情况下，所有在服务时到达的数据报都将丢失 - 没有 UDP 数据报排队。就像我说的，我不知道 MINA 是否可以针对并行数据报处理进行调整，但如果不能，那只是工具选择错误。
如果你想要可靠的传输，你应该使用 TCP。这将使您的发送速度几乎与较慢的网络和客户端一样快，没有任何损失。
如果您想要高度优化的低延迟传输，不需要可靠，您需要 UDP。这将使您发送的速度与网络可以处理的一样快，但您也可以发送得更快，或者比客户端读取的速度更快，然后您就会丢失数据包。
如果您想要具有细粒度控制的可靠的高度优化的低延迟传输，您将最终在 UDP 之上实现 TCP 的自定义子集。听起来你不能或不应该这样做。
... how can I get the best settings, or socket settings
通常通过实验。
如果丢失数据包的原因是客户端速度慢，则需要使客户端更快。较大的接收缓冲区只能购买固定数量的净空（比如吸收突发），但如果你系统地变慢，任何理智大小的缓冲区最终都会填满。
但是请注意，这只能解决过度或可避免的掉落问题。即使您的客户端可以跟上，各种网络堆栈层（即使不留下一个盒子）也允许丢弃数据包，因此如果没有自定义重传逻辑，您仍然不能将其视为可靠（我们又回到实现 TCP） .
... way to send as much as I can without being to much?
您需要某种 ack/nack/back-pressure/throttling/congestion/whatever 消息从接收者返回到源。这正是 TCP 免费提供给您的东西，您自己实现起来相对棘手。
Is it possible to reach something like 1MB/s ...
我刚刚看到 8MB/s 使用 scp over loopback，所以我会说 是的。它使用 TCP 并且显然选择了 AES128 来动态加密和解密文件 - 如果您只是发送明文，获得同等性能应该是微不足道的。