Path: utzoo!mnetor!uunet!husc6!im4u!ut-sally!ut-emx!clyde From: clyde@ut-emx.UUCP (Head UNIX Hacquer) Newsgroups: comp.sys.encore Subject: Re: why no inetd ? Message-ID: <2231@ut-emx.UUCP> Date: 9 May 88 14:50:15 GMT References: <2986@encore.UUCP> <8805031641.AA23695@archer.cs.brown.edu> Organization: Moose & Squirrel Software Lines: 29 FYI, we run 4.3BSD inetd and the 4.3BSD ftpd, telnetd, rlogind, etc. on our Multimax 320 and find there to be no visible performance problems. If you will think about it, a delay of a few milliseconds while inetd forks after accepting a connection should be no problem. Of course, if that fork gets held up due to, say, memory shortage it could be more troublesome. But if your system is in THAT bad of shape, you've got other more pressing concerns than the response time for rlogin requests. Having ONE central administration point for our network deamons (and one line in an 'rc' file) is much preferable to the 4.2 method. I am also puzzled why inetd is not part of UMAX (SUN did inetd a LONG time ago). There is one problem and that is the maximum number of open user file descriptors is only 32. So you have to keep a lid of the number of service ports that inetd listens to. This problem was fixed in 4.3 by raising the roof on file descriptors to 255 (or so). We also run the 4.3BSD syslogd, which is MUCH more useful that the old 4.2 (aka UMAX 4.2) version, as well as the init and getty from 4.3. We've also ported a lot of other 4.3 system stuff to the MultiMax and found them almost all very straightforward. -- Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas clyde@emx.utexas.edu; ...!ut-sally!ut-emx!clyde "It's a sort of a threat, you see. I've never been very good at them myself, but I've told they can be very effective."