While really really bored, Perry E. Metzger wrote:
> tholo@toad.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.

> If you want to run ftpd on a port other than the normal one, you can.
Depends on the daemon.  Most need software hacking (which isn't too hard).

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

c. It's harder to kill off a site with an FSP server
than with an FTP server.  The FSP daemon is designed to
be as lightweight as possible:  it doesn't fork off any
sub-processes, and it takes steps to limit the amount
of traffic it handles.

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.

>From the programmer's point of view, fsp is a complete rewrite.

a. Instead of TCP sockets, it uses datagrams to
communicate, so that the connection doesn't break on a
flaky line.

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.

c. The server tries to make sure you don't ask for
packets too quickly.  Each packet it sends out has a
random identification number, which the client must
return on the next request.  (If the client loses the
number, it must wait a few seconds before the server
accepts another packet from it).  Therefore, the client
has to wait for an answer to each request before it
sends out the next one.

Sounds like there's a few benefits to TCP that I didn't know of;
I've never done network programming so I can't say I've even heard of
many of the points made (re ICMP stuff, etc) - maybe FSP isn't as good.
However, at least on the surface, avoiding the overhead of realiable
streams seems good.  And doesn't nfs use UDP for a reason?
This has left the realm of NetBSD-current, please don't CC there.
-- 
VaX#n8 (vak-sa-nate) - n, CS senior++ and Unix junkie - vax@ccwf.cc.utexas.edu
Just the vax-man.  Read my MIPS, no new VAXes!        - PGP key on request