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, omere@tcmail.tau.ac.il ------------------\ [ 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