Java 哪个是按顺序发送大型 UDP 数据包的最佳方法
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/19057572/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Which is the best approach to send large UDP packets in sequence
提问by Fernando Siqueira
I have an android application that needs to send data through the protocol UDP every 100 milliseconds. Each UDP packet has 15000 bytes average. packets are sent in broadcast
我有一个需要每 100 毫秒通过 UDP 协议发送数据的 android 应用程序。每个 UDP 数据包平均有 15000 字节。数据包以广播方式发送
Every 100 milliseconds lines below are run through a loop.
下面每 100 毫秒运行一次循环。
DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, broadcast, 9876);
clientSocket.send(sendPacket);
Application starts working fine, but after about 1 minute frequency of received packets decreases until the packets do not arrive over the destination.
应用程序开始工作正常，但大约 1 分钟后接收数据包的频率会下降，直到数据包没有到达目的地。
The theoretical limit (on Windows) for the maximum size of a UDP packet is 65507 bytes
UDP 数据包最大大小的理论限制（在 Windows 上）为 65507 字节
I know the media MTU of a network is 1500 bytes and when I send a packet bigger it is broken into several fragments and if a fragment does not reach the destination the whole package is lost.
我知道网络的媒体 MTU 是 1500 字节，当我发送一个更大的数据包时，它会被分成几个片段，如果一个片段没有到达目的地，整个包就会丢失。
I do not understand why at first 1 minute the packets are sent correctly and after a while the packets do not arrive more. So I wonder what would be the best approach to solve this problem?
我不明白为什么在前 1 分钟数据包被正确发送，过了一段时间数据包没有到达更多。所以我想知道解决这个问题的最佳方法是什么？
采纳答案by David Schwartz
It's exactly the problem you described. Each datagram you broadcast is split into 44 packets. If any one of those is lost, the datagram is lost. As soon as you have enough traffic to cause, say, 1% packet loss, you have 35% datagram loss. 2% packet loss equals 60% datagram loss.
正是你描述的问题。您广播的每个数据报被分成 44 个数据包。如果其中任何一个丢失，数据报就会丢失。只要您有足够的流量导致 1% 的数据包丢失，您就会有 35% 的数据报丢失。2% 的数据包丢失等于 60% 的数据报丢失。
You need to keep your broadcast datagrams small enough not to fragment. If you have a stream of 65,507 byte chunks such that you cannot change the fact that you must have the whole chunk for the data to be useful, then naive UDP broadcast was badchoice.
您需要将广播数据报保持得足够小，以免分段。如果您有一个 65,507 字节块的流，以至于您无法改变必须拥有整个块才能使数据有用的事实，那么朴素的 UDP 广播是个糟糕的选择。
I'd have to know a lot more about the specifics of your application to make a sensible recommendation. But if you have a chunk of data around 64KB such that you need the whole chunk for the data to be useful, and you can't change that, then you should be using an approach that divides that data into pieces with some redundancy such that some pieces can be lost. With erasure coding, you can divide 65,507 bytes of data into 46 chunks, each 1,490 bytes, such that the original data can be reconstructed from any 44 chunks. This would tolerate moderate datagram loss with only about a 4% increase in data size.
我必须更多地了解您的应用程序的细节才能提出合理的建议。但是如果你有一个大约 64KB 的数据块，以至于你需要整个数据块才能有用，而且你不能改变它，那么你应该使用一种方法将这些数据分成具有一些冗余的部分，这样有些碎片可能会丢失。使用纠删码，可以将65507字节的数据分成46个块，每块1490字节，这样就可以从任意44个块重构原始数据。这将容忍适度的数据报丢失，数据大小仅增加约 4%。
回答by brak2718
TCP is used specifically instead of UDP when you need reliable and correctly ordered delivery. But assuming you really need UDP for broadcasting, you could:
当您需要可靠且正确排序的交付时，专门使用 TCP 而不是 UDP。但假设您确实需要 UDP 进行广播，您可以：
debug the network to see how & where packets are lost, or maybe it is the receiver that is clogged/lagged. But often you don't have control over these things. Is a WiFi network involved? If so it's hard to get good QoS.
do something on the application layer to ensure ordering and reliable delivery. For example, SIP normally uses UDP, but the protocol uses transactions and sequence numbers so clients & servers will retransmit messages as needed.
implement packet loss concealment. Using maths, the receiver can recreate a lost packet, analogous to how a RAID disk setup can lose drives and still function.
调试网络以查看数据包丢失的方式和位置，或者可能是接收器阻塞/滞后。但通常你无法控制这些事情。是否涉及 WiFi 网络？如果是这样，就很难获得良好的 QoS。
在应用层做一些事情，以确保有序和可靠的交付。例如，SIP 通常使用 UDP，但该协议使用事务和序列号，因此客户端和服务器将根据需要重新传输消息。
实现丢包隐藏。使用数学运算，接收器可以重新创建丢失的数据包，类似于 RAID 磁盘设置如何丢失驱动器但仍然可以工作。
That your setup works fine for a minute and then doesn't is a hint that there is either network congestion or software congestion on the broadcast or receiver side.
您的设置可以正常工作一分钟，然后并不暗示广播或接收器端存在网络拥塞或软件拥塞。
Can you do some packet captures with Wireshark and share the results?
你能用 Wireshark 做一些数据包捕获并分享结果吗？
