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."