MAX FILES PER PROCESS PROBLEM - (nf)

[dm%bbn-unix at sri-unix.UUCP]

From:  Dave Mankins <dm at bbn-unix>


Sorting aside, there are legitimate uses for allowing more than
20 open files to a process.  Our original implementation of TCP
(on an 11/70 running a modified version 6 UNIX many years ago)
was written as a user-mode program which was the only process
allowed to talk to the network device (a slight
oversimplification).  User programs (e.g., telnet, ftp, the
mailer) would then open up RAND ports (which are similar to
"named pipes") to talk with the TCP program, which, in turn
controlled communications with the network.  Limiting a process
to 20 open files means you can have only about 8 processes using
the network (network connections each take two files, one in each
direction, and it's nice to have a logging output file as well).

TCP is a large, complicated protocol, and is somewhat difficult
to fit into an 11's kernel space without coming up with an
overlay scheme (although I understand that someone at MIT has
succeeded in doing so).  It would also be nice if the kernel didn't
take up the entire memory of a small 11, and putting TCP in user
mode meant it could be swapped once in a while.

This was before there were VAXes, of course.