views:

338

answers:

2

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.

I have studied some UDP and I am aware of the following:

  • UDP has max size of about 65k.

  • However, it seems that iPhone can only receive 41k UDP packet. iPhone seems to not be able to receive packet larger than that.

  • 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.

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.

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?

A: 

Small packets is probably better than large packets :-)

St3fan
Sorry, but this doesn't help at all. Could you please elaborate further?
unknownthreat
A good practice of UDP applications is to keep the packet size under the MTU size so that there will be no fragmentation. Note that the MTU size is generally pretty low. Like 1396 bytes.
St3fan
+3  A: 

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 ):

  1. Add a sequence number to the header for each packet
  2. Ack each packet
  3. Set up a retransmit timer which resends the packet if no ack recv'ed
  4. Track latency RTT ( round trip time ) so you know how long to set your timers for
  5. Potentially deal with out of order data arrival if that's important to your app
  6. Increase receive buffer size on client socket.

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.

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 Nable disabled. It can also provide out-of-order delivery to speed things up even more.

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.

Robert S. Barnes