Re: Communciator 4.02 Imap EXPUNGE problem

[Mark Crispin <[e-mail]>]

On Mon, 25 Aug 1997 08:03:08 -0400 (Eastern Daylight Time), Barry Leiba,
Multimedia Messaging wrote:
> Then, again, there is nothing in the RFC that indicates that one shouldn't
> do this.  I repeat, yet one more time, that tossing criticism around for
> someone's "doing such a bizarre thing", and accusing that client of "highly
> anti-social" behaviour, when the client-writer followed the spec is
> inappropriate.

The practice of spawning multiple server processes in an effort to obtain
"better performance" *is* anti-social behavior, on the same order as setting a
TCP retransmission timer dramatically slow.

Remember that most of today's computers can only do one thing at a time;
multiprocessing is an illusion caused by fast switching.  The more things the
computer has to do, the less is available for doing any one thing.  This is
not linear, either; there is greater overhead from the switching.

It exploits a weakness in operating systems whose scheduler allocates by
process, instead of by user.  A client which spawns multiple server processes
(in *ANY* protocol -- this includes HTTP) seeks to grab a greater share of the
server's resources (and bandwidth to the server) to the detriment of clients
which do not.  It adds overhead to the server because these additional server
processes need to be scheduled.

The practice is ultimately self-defeating.  If you try to use certain browsers
with servers that have per-client limits, you'll discover that the performance
of those browsers rapidly collapses.

Claims to the contrary notwithstanding, the use of threads doesn't make this
problem go away; it simply sweeps it under the rug.  It is instructive to
study how threads are implemented.

> Instead, let's use these experiences to clarify the spec or
> to add to an "implementer's guide" that warns people against doing things
> that commonly deployed servers or mail stores or whatever can't handle well.

This isn't IMAP-specific.  It is a fundamental software engineering principle,
the sort of thing that belongs in CS 101.