如何使用C# UdpClient发送大数据？
我正在尝试使用 C# UdpClient 发送大量数据（超过 50 MB）。
所以首先我将数据分成65507字节块并循环发送它们。
for(int i = 0; i < packetCount; i++)
myUdpClient.Send(blocks[i], block[i].Length, remoteEndPoint);
我的问题是只能收到第一个数据包。 在发送第一个数据包期间，网络负载迅速增加到100%，然后无法接收其他数据包。
我希望获得尽可能多的数据吞吐量。
我为我的英语感到抱歉！ 提前感谢您的帮助。
I'm trying to send a large amount of data (more than 50 MB) using C# UdpClient.
So at first I split the data into 65507 byte blocks and send them in a loop.
for(int i = 0; i < packetCount; i++)
myUdpClient.Send(blocks[i], block[i].Length, remoteEndPoint);
My problem is that only the first packets can be received.
During sending the first packet the networkload increases rapidly to 100%, and then the other packets cannot be received.
I want to get as much data throughput as possible.
I'm sorry for my English!
Thanks for your help in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
对于所有那些说使用 TCP 的人来说……都是愚蠢的错误。虽然 TCP 是可靠的，并且窗口由内核维护，但它是相当“一劳永逸”的协议，但是当涉及到想要使用 100% 吞吐量的人时，TCP 就不行了（它节流得太厉害了，并且等待由于 RTT，ACK 会自动将至少 50% 的数据丢弃）。
对于最初的问题，您在该 for 循环中不间断地发送 UDP 数据包，窗口填满，然后任何新数据都会立即丢弃，甚至不会尝试上线。您还将数据分割得太大。我建议您构建自己的油门机制，以每秒 2k 段开始，然后慢慢增加。每个“段”包含一个 SEQ（确认或 ACK 的序列标识符）和 OFF（该数据集在文件内的偏移量）。当数据被标记时，让服务器跟踪这些标签。当另一方收到它们时，它将 SEQ 号存储在 ACK 列表中，并且任何丢失的 SEQ 号都会放入 NACK 计时器列表中，当计时器耗尽时（如果尚未收到），它将移至 NACK 列表。接收器应每隔几秒左右在单次传输中发送 ACK 列表中的 5 个左右 ACK 以及最多 5 个 NACK。如果发送方收到这些消息并且存在任何 NACK，则应立即限制并重新发送丢失的片段，然后再继续。已确认的数据可以从内存中释放。
祝你好运！
For all those people saying to use TCP....are foolishly wrong. Although TCP is reliable and the window maintained by the kernel it's fairly "set and forget" protocol, but when it comes to the guy wanting to use 100% of his throughput, TCP will not do (it throttles too hard, and the wait for an ACK automatically puts at least 50% trashed because of the RTT).
To the original question, you are sending UDP packets nonstop in that for-loop, the window fills up and then any new data is dropped immediately and doesn't even attempt to go on the line. You are also splitting your data too large. I would recommend building your own throttle mechanism that starts off with 2k segments per second, and slowly ramps up. Each "segment" contains a SEQ (sequence identifier for acknowledgements or ACK) and OFF (offset inside the file for this data set). As the data is being tagged, let the server keep track of these tags. When the other side gets them, it stores the SEQ numbers in an ACK list, and any missing SEQ numbers are placed into a NACK timer list, when the timer runs out (if they haven't been received) it moves to a NACK list. The receiver should send 5 or so ACKs from the ACK list along with up to 5 NACKs in a single transmission every couple seconds or so. If the sender receives these messages and there are any NACKs, it should immediately throttle down and resend the missing fragment before continuing. The data that is ACKed can be freed from memory.
Good luck!
我不知道具体的.Net实现，它可能会缓冲你的数据，但UDP数据报通常受到链接MTU的限制，在普通以太网上为1500（减去IP标头的20个字节和UDP标头的8个字节。）
UDP 被明确允许丢弃和重新排序数据报，并且没有 TCP 那样的流量控制。
超出发送方的套接字发送缓冲区将使网络堆栈忽略后续发送尝试，直到缓冲区空间再次可用（为此，您需要检查
send()的返回值。） ：
我强烈建议使用 TCP 进行大文件传输。 TCP 为您提供排序（您不必跟踪丢弃和重新排序的数据包。）它具有先进的流量控制（因此快速发送方不会压垮慢速接收方。）它还进行路径 MTU 发现（即找出最佳路径）数据打包并避免 IP 碎片。）否则您将不得不自己重新实现大部分功能。
I don't know about .Net implementation specifically, it might be buffering your data, but UDP datagram is normally limited by the link MTU, which is 1500 on normal ethernet (subtract 20 bytes for IP header and 8 bytes of UDP header.)
UDP is explicitly allowed to drop and reorder the datagrams, and there's no flow control as in TCP.
Exceeding the socket send buffer on the sender side will have the network stack ignore following send attempts until the buffer space is available again (you need to check the return value of the
send()for that.)Edit:
I would strongly recommend going with TCP for large file transfers. TCP gives you sequencing (you don't have to keep track of dropped and re-ordered packets.) It has advanced flow control (so fast sender does not overwhelm a slow receiver.) It also does Path MTU discovery (i.e. finds out optimal data packetization and avoids IP fragmentation.) Otherwise you would have to re-implement most of these features yourself.
我不想这么说，但你需要让线程休眠。您的吞吐量超载。 UDP 不太适合无损数据传输。 UDP 适用于您不介意丢弃一些数据包的情况。
I hate to say it but you need to sleep the thread. You are overloading your throughput. UDP is not very good for lossless data transfer. UDP is for when you don't mind dropping some packets.
可靠 - 不，您不会使用 UDP 来做到这一点。
据我了解，这对于一次发送到多台计算机（广播）是有意义的。
在这种情况下，
Reliably - no, you won't do it with UDP.
As far as I understand, this makes sense for sending to multiple computers at a time (broadcasting).
In this case,