Subject: Re: Archie-Clients
To: VaX#n8 <email@example.com>
From: Perry E. Metzger <firstname.lastname@example.org>
Date: 01/28/1995 14:47:23
> While really really bored, Perry E. Metzger wrote:
> > email@example.com says:
> > If someone wants to avoid having their server fork, you can build
> > servers that don't need to fork just as easily for TCP as for UDP.
> One kind of has to ask the question, then, why it hasn't been done.
> I know many ftpd's now don't fork for "ls", but really, one server per
> client is a pretty bad idea on a big ftp site.
Most people aren't really willing to work, thats all.
> > UDP is bad news for transmitting data in WANs; it doesn't do any of
> > the good congestion control or other things that TCP does.
> a. The protocol can stand things going down: if the
> server or the network falls over in the middle of a
> transfer, you can just wait until it comes back up.
> You don't have to reconnect, and even better, if the
> server went down 90% through grabbing a file, you can
> continue from where you left off.
> (meaning less resends)
FTP has a facility for dealing with partial file transmissions already.
> e. FSP is a bit slower than FTP. This is a feature,
> not a bug. The point is to keep the communication
> lightweight, and not to flood the net.
FSP is slower because it jams the line -- its no less of a network
load -- indeed its more of a load. It doesn't do congestion control,
so it ends up being slower for the same reasons NFS over UDP is slower
than, say, rcp.
> a. Instead of TCP sockets, it uses datagrams to
> communicate, so that the connection doesn't break on a
> flaky line.
TCP sockets don't break on flakey lines, either. TCP is implemented on
top of datagrams, you know.
> b. FTP works by opening a port, and then asking the
> server to send a file to it. FSP uses the same port
> all the time for communication, and asks for segments
> of a file. So you can start off a transfer half way
> through a file, if you really want to.
As I said, FTP can do the same.
> However, at least on the surface, avoiding the overhead of realiable
> streams seems good.
Its not overhead -- TCP is a good thing and is nearly as lightweight
> And doesn't nfs use UDP for a reason?
Actually NFS works better over TCP if its properly implemented --
especially on WANs.