george@tut.cis.ohio-state.edu (George M. Jones) (04/27/88)
It seems that (some) deamons are initiated differenty under Umax 4.2 than under other common flavors of Unix (SunOs, BSD 4.3). They seem to like to use a "master deamon", inetd, to fire up various other deamons as requests come in. This deamon is not distributed with Umax. I am curious as to why this difference exists. Anybody (Encore ?) care to comment ? Thanks ---George Jones -- OSU Computer & Info. Science 2036 Neil Ave., Columbus, Ohio 43210. 614-292-7325 george@cis.ohio-state.edu or ...!cbosgd!osu-cis!george Quality of life can be measured as the inverse of lawyers per thousand.
jb@CS.BROWN.EDU (Jim Bloom) (04/27/88)
My guess is that Encore has not gotten around to installing inetd yet or decided against it. Umax is based on 4.2BSD which did not have inetd. At some point between 4.2 and 4.3BSD, inetd reached both Berkeley and SUN who decided to add it to their systems. For the people at Encore listening, I think it would be a good idea to install inetd. Several new services contained in inetd get added to the system. Jim
loverso@encore.UUCP (John Robert LoVerso) (04/29/88)
Jim Bloom writes: > My guess is that Encore has not gotten around to installing inetd yet > or decided against it. Umax is based on 4.2BSD which did not have > inetd. At some point between 4.2 and 4.3BSD, inetd reached both Berkeley > and SUN who decided to add it to their systems. > > For the people at Encore listening, I think it would be a good idea to > install inetd. Several new services contained in inetd get added to the > system. Inetd is not part of UMAX4.2 because in fact we are still 4.2-based. While recent releases (R3.1.5 and B3.2) will contain more and more 4.3-based utilities, inetd won't appear in either of them. It could perhaps show up a tad later in the year when 4.3-based network code is phased in or released. Its easy to get 4.3 inetd running under UMAX, however. I've put it on xenna.arpa (192.5.63.63, the Annex engineering 310), but I'm only using it for its internal trivial services and one or two other things. Something that will probably be considered before we commit to inetd for services like login, telnet, shell, etc, is whether or not there will be a performance penalty in single threading the listening end of all those services? This is important for the Multimax, considering that as it sits now, rlogind and telnetd can both be accepting a connection at the same time. However, I would probably lay odds that any such performance penalty will be insignificant. John R LoVerso, Encore Computer Corp loverso@multimax.arpa, encore!loverso
jb@CS.BROWN.EDU (Jim Bloom) (05/03/88)
Something that will probably be considered before we commit to inetd
for services like login, telnet, shell, etc, is whether or not there will
be a performance penalty in single threading the listening end of all those
services? This is important for the Multimax, considering that as it
sits now, rlogind and telnetd can both be accepting a connection at the
same time. However, I would probably lay odds that any such performance
penalty will be insignificant.
Yes, performance will take a slight hit. The delay should only be about
the same as when telnet or rlogin gets two connection requests at the same
time. Unless the machine is getting on the order of tens of connection
requests per second (or maybe more), the effect should be unnoticable.
If you look at most machines, I'd say the connection request rate more
likely averages on the order of one per minute (for all services under
inetd). The burst rate is higher, but I still don't think it is anywhere
near fast enough to cause problems. The limiting factor here will be
how fast can inetd fork.
Jim Bloomclyde@ut-emx.UUCP (Head UNIX Hacquer) (05/09/88)
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."