3

My application needs to send video data frame by frame from Server to Client. I'm wavering between using TCP or UDP.

From my test, I found out some following results:

TCP: Very easy to implement.

UDP: To send a frame (about 50KB) to Client, if I create 1 UDP package for each frame then the sending always loses frames. So I must divide each frame into many UDP packages. This makes my algorithm much more sophisticated because UDP protocol can lose packages and the packages can be delivered out of order. In addition, if the length of data in each UDP package is large then it is easily lost.

I have some questions:

  1. Should I use TCP or UDP for this type of application.

  2. If I want to use UDP for faster transmission, how to determine the suitable length of data in each package that won't be lost easily while transmission? (this maybe belong to network bandwidth)?

  3. From your experiences, can you estimate how much percent is TCP faster UDP?

Sorry for so many questions in a post, but I need to know more details before deciding whether to use TCP or UDP in my application.

Dale K
  • 25,246
  • 15
  • 42
  • 71
TTGroup
  • 3,575
  • 10
  • 47
  • 79
  • 3
    http://www.skullbox.net/tcpudp.php , udp is commonly used for audio and video, so possibly for your application it'd be more suitable – theBigChalk Jun 18 '12 at 13:52

3 Answers3

5

Since your application streams video you probably want UDP. One huge difference between TCP and UDP (in this case) is that UDP does not try to recover lost packets as TCP does. You do not want a video to reload every time a frame is skipped because it will take a long time, instead UDP will just skip lost frames. (If you right-click on a Youtube video youcan see the number of packets dropped while streaming a video)

pennetti
  • 145
  • 6
  • 1
    Apologies, I don't know about a percentage but you can look at http://stackoverflow.com/questions/47903/udp-vs-tcp-how-much-faster-is-it for some more information about the speed difference. – pennetti Jun 18 '12 at 16:36
3

In your case I'd use TCP unless you actually have hands-on experience with fragmenting and re-assembling UDP packets manually, and you're willing to maintain the overhead introduced in your code (like having a re-assembling buffer and controlling the latency that this implies).

Furtherly, you should take the targetted network into consideration. Is it localhost only, a LAN, a WAN or even the internet. The less control you have over the network the higher the impact of favouring TCP in terms of roundtrip times, latency, packet loss, etc. By control I mean upper bounds or estimates of the number of crossed network segments (#routers), the number of different configurations (QoS, bandwidth-limiter, MTU, ...), and so on.

As a rule of thumb, UDP is great when all data necessary for an instant (defined below) fits in one packet (MTU is guaranteed to be 1280 in IPv6). An instant is a short snapshot in time, something that typically has a life-span of a round trip time. UDP is also great for conversations where both the query and the response are small entities.

So in this sense, I'd use UDP for something like DNS (short query, short answer), or financial transaction data (there's only so many within the life-span of 1 round trip time), or protocol meta data such as the number or identity hashes of participating clients (query/response short and there's only a handful within the roundtrip time).

Hope this helps.

Edit:
To answer your questions

  1. UDP (restrictions listed above)
  2. IPv6 offers path mtu detection, you'd simply use the PMTU, for IPv4 you'd have to roll your own:
    • set the IP_DONTFRAG socket option
    • send a packet that you would assume goes through
    • think of a simple protocol to allow the receiver to tell you whether the packet has been received completely
    • if no -> reduce the size, if yes -> increase the size
    • after a few ping-pongs you have a safe estimate for the PMTU (of course you can send payload data along already)
  3. UDP will outperform TCP substantially if the nature of the network is stable and remains stable. (Conversely) TCP will not win when the nature of the network keeps changing (latency variations, changing probability of packet loss, etc.) But, on the same note, UDP will not win when the network segments are very far apart and QoS is used in some of the intermediate segments (QoS that is configured to favour more or less known TCP services over ``other'' stuff.

For some figures and inspiration you should check out udt.

hroptatyr
  • 4,702
  • 1
  • 35
  • 38
  • 1
    What? You'd use UDP for financial information, but TCP for video streaming that has real-time constraints? This is very backwards from best practices. – Oleksi Jun 18 '12 at 14:04
  • 2
    No, **I**'d use UDP in this case as well, provided I have control over the codec. And I think compared to financial data video streaming is much more relaxed in terms of latency, so long as it remains constant. – hroptatyr Jun 18 '12 at 14:14
0

Apart from video/audio streaming UDP is used for low-latency applications that have short messages.

Ivan Voroshilin
  • 5,233
  • 3
  • 32
  • 61