[
Lists Home |
Date Index |
Thread Index
]
On Tue, 22 Jan 2002, Tim Bray wrote:
> Granted. But to the list of HTTP's virtues we should add:
>
> 1. It's here and deployed and debugged and well-understood
As are many other things, mind. Never ever forget that almost every UNIX
install (*certainly* ever open source Unix - Linux, NetBSD, FreeBSD, and
OpenBSD, and probably Minix too) comes with an ONC RPC implementation.
These things have been in operation for ages. NFS works over ONC RPC, as
does NIS, and a few minority protocols. It's the backbone of a LOT of
working systems out there.
> 2. It seems to degrade remarkably gracefully under pressure (I
> still don't understand why this is the case)
Really? Compared to what? I've never seen this... HTTP, like all TCP-based
protocols, seems to deal very badly with high packet loss.
Consider a stream of requests coming in over a TCP connection. If one
packet is missing, all packets after that one will be delayed until the
missing packet is retransmitted. They sit in kernel memory, buffered,
while the server process is blocked waiting for the missing packet.
This sucks.
UDP has no such problem; it only arises because TCP is trying to emulate a
serial line.
If you want UDP packets ordered, then by all means use a sequence number,
or actually use TCP if the semantics of a serial line are what you need.
But I've seen so many protocols enforce some kind of framing on top of TCP
- HTTP does this too - just because TCP has gone to quite a lot of effort
to hide the fundamental framing of the underlying network protocol.
> -Tim
ABS
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software
|
