Message-Id: <199708141651.MAA07566@jekyll.piermont.com>
To: "D. J. Bernstein" <djb@koobera.math.uic.edu>
cc: drums@cs.utk.edu
Subject: Re: speeding up QUIT 
In-reply-to: Your message of "14 Aug 1997 16:35:46 -0000."
             <19970814163546.24963.qmail@koobera.math.uic.edu> 
Reply-To: perry@piermont.com
Date: Thu, 14 Aug 1997 12:51:33 -0400
From: "Perry E. Metzger" <perry@piermont.com>


"D. J. Bernstein" writes:
> > What, exactly, is it that Dan Bernstein's "optimization" buys?
> 
> Nearly 10% more mail delivered in the same time with the same memory.

Only if so much of the rest of your system is misdesigned that it
would make a difference -- in which case so much of the rest must be
junky that I suspect you could produce far bigger benefits by other
alterations.

Now, I'm sure that Sendmail is grotesquely inefficient in this regard
(it is just not the right tool for the job any longer) but that
doesn't mean that if someone wants to build a better mailer the answer
is to get rid of QUIT.

> Also a slight bandwidth reduction in some cases---more, in fact, than
> the maximum possible savings from multiple RCPTs at most sites.

I don't believe you. Period.

BTW, the only reason your RCPT hack works at all is because some
systems take so long to answer an RCPT -- if you benchmark this on a
LAN, it "looks good". However, if you have a multi-threaded or event
driven delivery program, you don't really have any reason to CARE how
long a single delivery stream gets blocked because others are going
just fine in parallel to it, and total throughput is utterly
untouched. OTOH, your RCPT hack has the ugly feature that if you are
sending mail to 100 people at a site, you have to send the message
text 100 times. This is a large use of bandwidth -- and frankly, I
don't see how it can be anywhere near what the removal of QUIT is --
after all, removing QUIT at best buys you under 100 bytes of TCP
channel bandwidth.

> > while you are "waiting" for QUIT you
> > are taking up virtually no resources at all,
> 
> Idiot.

Thank you for your intellectual discourse.

Let us examine your statement in detail.

What exactly would harm you in an event driven mail delivery program
(like the experimental one we built here at Piermont)?

Well, you'd hold open about a couple of K of memory for various data
structures associated with the open socket, and to note that you had
an open connection to a particular host's SMTP port. That's it. By my
book, you can afford a couple of K of memory -- memory is bloody cheap
these days, and even if over a few hundred simultaneous connections
that represents a meg of memory the cost of the memory is so low
in dollars that I'm not sure its worth thinking about.

Now, perhaps I'm an "idiot" for pointing this out, Dan, but if so I'm
an idiot in good company.

Perry