Path: utzoo!mnetor!uunet!husc6!linus!encore!loverso
From: loverso@encore.UUCP (John Robert LoVerso)
Newsgroups: comp.sys.encore
Subject: Re: why no inetd ?
Message-ID: <2986@encore.UUCP>
Date: 28 Apr 88 18:13:10 GMT
References: <11681@tut.cis.ohio-state.edu> <8804271245.AA20208@archer.cs.brown.edu>
Reply-To: loverso%xenna@Multimax.ARPA (John Robert LoVerso)
Organization: Encore Computer Corp, Marlboro, MA
Lines: 30

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