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.  :-)

-- 
-Chuck