通过 UDP 套接字发送的限制
我有一个 1GB 的大文件，我正在尝试将其发送到另一个节点。发送方发送 200 个数据包后（发送完整文件之前）代码跳出。说“发送到没有可用的发送空间”。可能是什么问题以及如何处理它。
除此之外，我们需要在此传输中实现最大吞吐量。那么我们应该使用多大的发送缓冲区才能提高效率呢？
我们可以用来传输文件而不产生碎片的最大 MTU 是多少？
谢谢 里图
谢谢你的回答。实际上，我们的项目指定使用 UDP，然后使用一些附加代码来处理丢失的数据包。
现在我可以使用阻塞 UDP 套接字发送完整的文件。
我在一个类似仿真环境的环境（称为 deter）上运行整个设置。我已将链路丢失设置为 0，但我的一些数据包仍然丢失。这背后可能的原因是什么？即使我在发送每个数据包后添加延迟（假设接收器在缓冲区已满时丢弃数据包）......该数据包丢失仍然存在。
I have a big 1GB file, which I am trying to send to another node. After the sender sends 200 packets (before sending the complete file) the code jumps out. Saying "Sendto no send space available". What can be the problem and how to take care of it.
Apart from this, we need maximum throughput in this transfer. So what send buffer size we should use to be efficient?
What is the maximum MTU which we can use to transfer the file without fragmentation?
Thanks
Ritu
Thank you for the answers. Actually, our project specifies to use UDP and then some additional code to take care of lost packets.
Now I am able to send the complete file, using blocking UDP sockets.
I am running the whole setup on an emulab like environment, called deter. I have set link loss to 0 but still my some packets are getting lost. What could be the possible reason behind that? Even if I add delay (assuming receiver drops the packet when its buffer is full) after sending every packet..still this packet losts persists.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
可以使用 UDP 进行高速数据传输，但您必须确保 send() 数据的发送速度不要快于网卡将数据传输到线路上的速度。实际上，这意味着要么使用阻塞 I/O，要么阻塞 select() 并仅在 select() 指示套接字已准备好写入时发送下一个数据包。 （理想情况下，您发送数据的速度也不会快于接收机器接收数据的速度，但这已不是什么问题，因为现代 CPU 速度通常比现代网络 I/O 速度快得多）
一旦您的逻辑正常工作，发送缓冲区的大小并不是非常重要。 （即无论如何，您的发送缓冲区永远不会大到足以容纳 1GB 文件，因此无论发送缓冲区是大还是小，确保您的程序不会溢出发送缓冲区是关键问题）接收缓冲区的大小不过，接收器很重要……最好使其尽可能大，这样，如果接收进程被另一个程序阻止 CPU，接收计算机就不会丢弃数据包。
关于 MTU，如果您想避免数据包碎片（并假设您的数据包通过以太网传输），那么您不应在每个 UDP 数据包中放置超过 1468 字节（如果您使用 IPv6，则不应放置超过 1452 字节）。 （通过从以太网的 1500 字节帧大小中减去必要的 IP 和 UDP 标头的大小来计算）
It's possible to use UDP for high speed data transfer, but you have to make sure not to send() the data out faster than your network card can pump it onto the wire. In practice that means either using blocking I/O, or blocking on select() and only sending the next packet when select() indicates that the socket is ready-for-write. (ideally you'd also not send the data faster than the receiving machine can receive it, but that's less of an issue these days since modern CPU speeds are generally much faster than modern network I/O speeds)
Once you have that logic working properly, the size of your send-buffer isn't terribly important. (i.e. your send buffer will never be large enough to hold a 1GB file anyway, so making sure your program doesn't overflow the send buffer is the key issue whether the send buffer is large or small) The size of the receive-buffer on the receiver is important though... best to make that as large as possible, so the receiving computer won't drop packets if the receiving process gets held off of the CPU by another program.
Regarding MTU, if you want to avoid packet fragmentation (and assuming your packets are traveling over Ethernet), then you shouldn't place more than 1468 bytes into each UDP packet (or 1452 bytes if you're using IPv6). (Calculated by subtracting the size of the necessary IP and UDP headers from Ethernet's 1500-byte frame size)
也同意@jonfen。没有用于高速文件传输的 UDP。
UDP 产生的协议开销较少。然而，在最大传输速率下，传输错误是不可避免的（例如丢包）。因此必须结合 TCP 之类的纠错方案。最终结果低于 TCP 性能。
Also agree with @jonfen. No UDP for high speed file transfer.
UDP incur less protocol overhead. However, at the maximum transfer rate, transmit errors are inevitable (such as packet loss). So one must incorporate TCP like error correction scheme. End result is lower than TCP performance.