Mark Wieder wrote:
There are a few other circumstances where you might want to choose UDP rather than TCP, apart from the speed and low overhead cases.I normally tend to shy away from using udp, but there are areas where you really need it (working with existing protocols for other apps, etc.). Using udp can also bring up firewall issues.
I think of it this way: udp is packet-oriented while tcp is stream-oriented. Udp gives you speed and low overhead but packets aren't guaranteed to arrive. Tcp guarantees that the packets arrive at the destination and arrive in order, but the message can be broken up into an arbitrary number of packets (Elvi shasle ftt hebuil ding).
With udp the entire message (if it arrives) is in a single packet. With tcp you have to parse the incoming stream to determine where the information ends.
1. Data is time-sensitive (or delay-, or jitter-sensitive), but not loss-sensitive
Obvious example is streaming audio or video, particularly in real-time or conversational mode. Most audio codecs are designed to be robust in the face of packet loss (e.g. audio samples spread over adjacent packets), but delays (which would be enforced by TCP NAKs and retransmits) are audible (visible) to the users. The most common example of this today is VOIP, and that mostly uses RTP over UDP, rather than over TCP; however, the commercial streaming audio formats are often run over TCP (with bigger buffering to handle TCP-induced delays) because of firewall problems.
2. High bandwidth high latency networks.
If you need to deliver large files over high-latency networks such as satellite, the effects of the very high round-trip times can be dramatic, preventing TCP connections from using the full bandwidth in many cases. It may be easier to use UDP in conjunction with a delayed re-transmit mechanism (if you can ensure that the received data isn't used until the retransmit happens later), or with FEC (Forward Error Correction) to allow complete data reception even when some packets are lost.
3. Multicast or Broadcast.
TCP can't be used in either multicast or broadcast cases - but UDP can. In most cases where you have multiple receivers, it's clear that TCP is the wrong "style" of transport, and UDP is more natural.
If you really wanted something like TCP but sending to multiple receivers, I'd reckon you want to use PGM rather than rolling your own in UDP (but as a co-author of PGM, I'm biased :-)
(And unfortunately, Rev doesn't support either multicast or PGM).
(Actually, I think Rev doesn't fully handle broadcast - I can get it to send to a local-broadcast address and they are received by other devices - but I can't get Rev to receive them ... will experiment some more with that later)
4. Low frequency (or very low frequency) packet exchange.
For example, if you want to send one packet of info every hour (or every day), then you wouldn't want to keep a TCP connection open (in many cases, you couldn't keep the connection open because of transient problems), and wouldn't want the overhead of opening a TCP connection, sending one packet, and closing the connection again. (Maybe this is just a special case of the low-overhead advantage - but is different in that a single, persistent TCP connection isn't a viable option at all).
5,6,7 ..... There are others, but we're starting to get into the esoteric cases now.
In general, my advice would be - always use TCP except when you can't.
-- Alex Tweedly http://www.tweedly.net
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.5.3 - Release Date: 01/03/2005
_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
