Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!pasteur!ucbvax!lcs.mit.edu!sra
From: sra@lcs.mit.edu (Rob Austein)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: UDP - How unreliable?
Message-ID: <8912141305.aa00864@mintaka.lcs.mit.edu>
Date: 14 Dec 89 18:05:42 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 26


   Date: 14 Dec 89 15:08:55 GMT
   From: amanda@mermaid.intercon.com (Amanda Walker)
   ...
   UDP is most useful as a cheap way to get packets around a local network
   when retransmission is either unnecessary or easy to figure out how to do.
   For any application that needs to work over arbitrary distances or needs
   confirmation that the data actually got to the other end, TCP is probably
   the way to go.

This is of course a good general rule, but there is at least one
important special case where UDP is (arguably) the right sollution for
a protocol that works over arbitrary distances: a configuration with a
huge number of clients asking short, infrequent questions of a few
global servers.  For example, the Domain Name System, where every host
on the internet needs to check with one of the half dozen root servers
once a week (assuming everybody is implementing the protocol correctly
and no machine ever needs to be rebooted or has its cache flushed...).

In this kind of configuration, the connection setup involved in using
TCP is quite expensive: the shortest likely TCP exchange would require
two packets in each direction, and the additional overhead for setting
up the TCB on the server might add significantly to the query
processing cost.

--Rob Austein