UDP sockets - again

Alex Tweedly alex at tweedly.net
Tue Mar 1 20:17:54 EST 2005


Mark Wieder wrote:

> 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.
>
There are a few other circumstances where you might want to choose UDP 
rather than TCP, apart from the speed and low overhead cases.

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



More information about the use-livecode mailing list