guy keren wrote:
>
[my original ramblings snipped]
>
> omer, you need to make one major distinction here between suggestions to
> programmers and suggestions to systems administrators.
Guy, I have no clue how you dragged programmers into it.
If a program knows to multiplex or not is really not
the issue, but rather an extra benefit of running
in daemon mode. I'm not making suggestions to anyone
in here, I'm debating a point (hopefully to the benefit
of all sides involved).
>
> it is up to the programmer to write their server in a multiplexing manner.
> if you, as a sys admin, need to use one server that was written by someone
> else, you are confined to using its existing abilities. if it was written
> to be launched via inetd, then that's how you'll have to run it. if it was
> written so it can work either from inetd, or as its own daemon, then you,
> as an administrator, have the option of checking if it's daemonized mode
> is indeed more efficient (as leonid pointed out - this is not always the
> case), and if so - run it like that.
>
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).
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. 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).
> 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). 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).
>
> now, if you wish to show us of a pop server that works in a multiplexing
> manner, and can actually scale up to supporting many clients - _that_
> would be a good contribution to our knowledge. i personally will be happy
> to know that. please tell us, and let us see the light :)
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).
Again, tcpserver is always an option (no need for tcpd, in this case).
>
> thanks in advance,
>
> guy
--
/--------------- Omer Efraim, [EMAIL PROTECTED] ------------------\
[ Microsoft Vaccine 2000 is configuring your immune system. This may ]
[ take a few minutes. If your body stops responding for a long time and ]
[ there is no brain activity please die. Setup will continue after you ]
[ are reborn. ]
\-----------------------------------------------------------------------/
- Quoting Buzh, asr
S/MIME Cryptographic Signature
