通过 UDP 从服务器向 iPhone 发送大量实时处理的数据 [英] Sending a huge amount of real time processed data via UDP to iPhone from a server
问题描述
我正在实现一个远程应用程序.服务器将处理 &以动画形式实时渲染数据.(准确的说是一系列图片)每次渲染一张图片，都会通过UDP传输到接收端的iPhone客户端.
I'm implementing a remote application. The server will process & render data in real time as animation. (a series of images, to be precise) Each time, an image is rendered, it will be transferred to the receiving iPhone client via UDP.
我研究了一些 UDP，我知道以下几点:
I have studied some UDP and I am aware of the following:
UDP 的最大大小约为 65k.
UDP has max size of about 65k.
但是，iPhone 似乎只能接收 41k 的 UDP 数据包.iPhone 似乎无法接收比这更大的数据包.
However, it seems that iPhone can only receive 41k UDP packet. iPhone seems to not be able to receive packet larger than that.
发送多个数据包时，会丢弃许多数据包.这是由于过大的 UDP 处理.
When sending multiple packets, many packets are being dropped. This is due to oversizing UDP processing.
减小数据包大小会增加未被丢弃的数据包数量，但这意味着需要发送更多数据包.
Reducing packet size increase the amount of packets not being dropped, but this means more packets are required to be sent.
我以前从未编写过真正实用的 UDP 应用程序，因此我需要一些指导以实现高效的 UDP 通信.在这种情况下，我们讨论的是从服务器实时传输渲染图像以在 iPhone 上显示.
I never write real practical UDP applications before, so I need some guidance for efficient UDP communication. In this case, we are talking about transferring rendered images in real time from the server to be displayed on iPhone.
压缩数据似乎是强制性的，但在这个问题中，我想重点关注 UDP 部分.通常情况下，当我们实现 UDP 应用程序时，如果我们需要实时不间断地发送大量数据，我们应该如何进行高效 UDP 编程的最佳实践?
Compressing data seems mandatory, but in this question, I would like to focus on the UDP part. Normally, when we implement UDP applications, what can we do in terms of best practice for efficient UDP programming if we need to send a lot of data non-stop in real time?
推荐答案
假设您有一个非常具体和充分的理由使用 UDP，并且您需要所有数据到达(即您不能容忍 任何 丢失数据)那么您需要做一些事情(假设是单播应用程序):
Assuming that you have a very specific and good reason for using UDP and that you need all your data to arrive ( i.e. you can't tolerate any lost data ) then there are a few things you need to do ( this assumes a uni-cast application ):
- 为每个数据包的标头添加一个序列号
- 确认每个数据包
- 设置一个重传计时器，如果没有收到确认，则重新发送数据包
- 跟踪延迟 RTT(往返时间)，以便您知道将计时器设置为多长时间
- 如果这对您的应用很重要，可能会处理乱序数据到达
- 增加客户端套接字上的接收缓冲区大小.
此外，您的发送速度可能非常快，以至于您在发送机器内部丢弃了数据包，甚至没有将 NIC 放到网络上.在某些系统上，在发送套接字上调用 select 以获得可写性可以帮助解决这个问题.此外，在 UDP 套接字上调用 connect 可以提高性能，从而减少丢包.
Also, you could be sending so fast that you are dropping packets internally on the sending machine without them even getting out the NIC onto the wire. On certain systems calling select for write-ablity on the sending socket can help with this. Also, calling connect on the UDP socket can speed up performance leading to less dropped packets.
基本上，如果您需要保证数据按顺序交付，那么您将在 UDP 之上重新实现 TCP.如果您使用 UDP 的唯一原因是延迟，那么您可能可以使用 TCP 并禁用 Nagle 算法.如果您想要具有可靠低延迟交付的打包数据，另一种可能性是 SCTP，同时禁用 Nagle.它还可以提供乱序交付以进一步加快速度.
Basically, if you need guaranteed in-order delivery of your data than you are going to re-implement TCP on top of UDP. If the only reason you use UDP is latency, then you can probably use TCP and disable the Nagle Algorithm. If you want packetized data with reliable low latency delivery another possibility is SCTP, also with Nagle disabled. It can also provide out-of-order delivery to speed things up even more.
我会推荐 Steven 的Unix 网络编程"，其中有一个关于高级 UDP 的部分以及何时适合使用 UDP 而不是 TCP.作为说明，他建议不要使用 UDP 进行批量数据传输，尽管现实情况是，如今这在流媒体多媒体应用中变得越来越普遍.
I would recommend Steven's "Unix Network Programming" which has a section on advanced UDP and when it's appropriate to use UDP instead of TCP. As a note, he recommends against using UDP for bulk data transfer, although the reality is that this is becoming much more common these days for streaming multimedia apps.
这篇关于通过 UDP 从服务器向 iPhone 发送大量实时处理的数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
