On Sat, 29 Jan 2000, Omer Efraim wrote:
> That's quite irrelevant for several reasons.
> The most notable one is that I stated that I have no knowledge
> of qpopper, and am rather talking about a general inetd'ish
> approach. Now, there is always an option of not running through
> inetd: How about tcpserver? (Of Unix Client-Server TCP, ucspi).
ah - now you're talking. all this time, you carried along the assumption
that we all know about the existance of this so-called 'tcpserver'...
well, i never heard of that, and i'll go check out what that is...
> FYI, by default, inetd will disable access to a service
> after a certain number of connections in a single
> minute (yes, it can be changed).
> A downside to inetd, as I pointed out, is that if one process
> brings it down, then it takes all the other services running
> from within it as well.
aha. this is indeed an important point.
> In addition to that, inetd is ONE process.
> If connections to multiple services come in, and inetd is busy
> forking one program to deal with one of the services, it won't
> be able to handle other connections until it's done (especially
> matters when using multiple processors).
this all sounds like inetd should be rewritten to acomodate for these
"modern" times... this is an idea for a skeletal library that'll make it
easy to write multi-process (supporting all kinds of multi-process models)
and multi-threaded servers (and clients too??). hmm. i'm too lazy to do
that, i'm afraid. well, maybe one day...
> > now, as far as i know, all mail reading servers i've see (that'd probably
> > include qpopper, and one or two imap servers) are running one process per
> > client, and do not multiplex several clients using a single process. in
> > such a case, a system's administrator only option is running the pop/imap
> > server from inetd, and then using tcpd to actually launch the server is a
> > good idea, even if it incures some more overhead on the machine.
>
> For most traditional mailing systems (which have a spool, or a
> sort of spool directory, even a Maildir), that's a must, as they need to
> change
> to the user's uid before reading his mail and starting the pop3
> transfer (Leonid pointed this out to me in a previous mail).
well, they don't _HAVE_ to. they do that strictly for security purposes
(i.e. not wanting the server to run as 'root' when it does not have to).
> However,
> enterprise
> systems do not use this method, and have one pop3 process which might
> just pre-fork, or pre-fork+ multiplex (I've never bothered checking).
> Lotus Notes
> is a good example, and OpenMail should be able to do the same (neither
> needs to assume
> a different UID).
hmm. more case for such a library. the free software needs that in order
to allow its servers to scale better. perhaps some code could be stolen
from apache to serve as the basis for the pre-forking model's
implementation...
> Again, whether or not the pop server knows how to multiplex or not doesn't
> have anything to do with it. Running out of inetd is still not a Good
> Idea(tm),
> and running daemon mode almost certainly will have more advantages (again,
> only
> on dedicated servers since the daemon always needs to be running.Having
> the
> pop3/ftp/telnet/imap servers always in memory on most normal servers is
> useless
> and consumes resources. And even on a dedicated server, you'd probably
> still
> have telnet/finger(ahem) still running from inetd, as long as they are not
> public access systems).
well, i'm not sure that keeping them as dedicated servers is such a big
deal - they'll get paged out soon enough, and wouldn't hurt the system.
well, _this_ letter made much more sense (to me) then your original one.
and i should smack myself on the head for not thinking about this 'single
point of failure' problem myself.
thanks,
guy
"For world domination - press 1,
or dial 0, and please hold, for the creator." -- nob o. dy
