Subject: Re: Slow UDP traffic
To: None <netbsd-users@NetBSD.org>
From: Chuck Swiger <email@example.com>
Date: 06/10/2004 18:07:56
Marc Tooley wrote:
[ ... ]
> TCP guarantees in-order delivery.
To the user application, sure. TCP doesn't guarantee that individual packets
get delivered in order.
> If you relax this and one or two of
> the other constraints TCP operates under, you can sometimes eke out
> more speed from it if you are delivering defined, discrete chunks of
> data like files.
Certainly, if this higher-level protocol duplicates some of the functionality
built into TCP and has it's own mechanisms for tracking a stream of data in
terms of content length, checksums (lots of compressed or tar'ed files have
this kinda stuff), or content ranges for things using HTTP to support partial
queries and resuming partial downloads.
FreeBSD has experimented with using T/TCP, but I haven't seen signs that many
people want to go that route. Running HTTP over a UDP-based protocol and
using content-range requests to fill in any dropped UDP packets might be
interesting, or perhaps for proxies like Squid to exchange cached content rapidly.
> Mostly I've seen applications (such as vtun) shred any sane use of UDP
> entirely and *seem* to ignore the possibility of optimising thing any
> for relatively quicker network environments.
Well, network programming is hard to do well, so it's not too hard to find
less-than-ideal examples out there. :-)