Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!ucbvax!world.std.com!bzs
From: bzs@world.std.com (Barry Shein)
Newsgroups: comp.protocols.tcp-ip
Subject: Beginner's info TCP & UDP
Message-ID: <9007201804.AA04495@world.std.com>
Date: 20 Jul 90 18:04:33 GMT
References: <81247@srcsip.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 61


>Quick question:
>	Under what conditions would a programmer want to use a UDP connection
>	over a TCP connection? What does UDP give you that TCP doesn't, that
>	makes it worth losing (or implementing yourself) a reliable,
>	guaranteed delivery layer?
>
>	Pete Clark

I assume you mean UDP over IP, not over TCP, otherwise it's not a
quick question, it's a strange question and needs some clarification.

Consider the following situations:

1. I have designed an application which embeds ECC integers and
sequencing into its packets. It's mostly a one-way protocol (on
request blasts a lot of data), so asynchrony is not particularly
useful. The ECC allows the remote end to detect and correct one or two
bit errors without resend. I have determined (?) that 99.99% of all
errors are one or two bit (of course, sequence errors might require
entire resends, but I can handle that.)

Why would I want TCP to also check every packet and silently resend
when most of the time I can correct without resend?

2. I am sending an animation which consists of 1Kx1Kx8 bit frames over
the network. I do some rudimentary checking (sequencing etc.) but,
more importantly, need to (usually) keep up with 30-frames/second.

A few bits in error might mean the image on the screen is "smudged" in
some tiny area for 1/30th of a second (this assumes a network
connection with few errors, tho not zero errors.)

Is it worth waiting and having TCP resend those packets? Or just let
the screen update on the next 30th of a second which will probably fix
the image (that is, would anyone notice a few small xmit errors?)

3. I am blasting data similarly to (2) over ethernet. Ethernet
hardware does a CRC on the data although, again, doesn't guarantee
sequencing (packets might be lost entirely, but if they get there
they're correct.)

4. Finally, UDP/IP can be implemented on a machine with raw access to
a network device in a (longish) afternoon. I've done it (the 3B2/HP
UDP/IP/TFTP source that floats around was written by me from scratch
and put into production over a weekend.)

There is value in getting a few bits across as a bootstrap.

Caveat: It is a fallacy that because UDP is much simpler and lower
overhead that it is therefore inherently faster. For example, the
lockstep protocol of TFTP/UDP is usually much, much slower (an order
of magnitude) than a decent FTP/TCP. Asynchrony is much more important
than mere CPU cycles. Ask the right questions!

(note that in the examples above I haven't excluded asynchrony.)

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD