Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!security!genrad!grkermit!masscomp!clyde!floyd!harpo!seismo!hao!hplabs!sri-unix!dm@bbn-unix From: dm%bbn-unix@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: MAX FILES PER PROCESS PROBLEM - (nf) Message-ID: <14637@sri-arpa.UUCP> Date: Thu, 15-Dec-83 17:48:30 EST Article-I.D.: sri-arpa.14637 Posted: Thu Dec 15 17:48:30 1983 Date-Received: Tue, 20-Dec-83 01:42:24 EST Lines: 24 From: Dave Mankins 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.