Subject: Re: Archie-Clients
To: VaX#n8 <>
From: Perry E. Metzger <>
List: current-users
Date: 01/28/1995 14:47:23
VaX#n8 says:
> While really really bored, Perry E. Metzger wrote:
> > 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
as possible.

> And doesn't nfs use UDP for a reason?

Actually NFS works better over TCP if its properly implemented --
especially on WANs.