On 22 Aug 2011, at 15:04, Dave CROCKER wrote:
I see a couple of folk suggesting that this thread has run its course. I've
been wondering about that.
Given how long the thread has been and how much senior email talent has
contributed to it, I'm entirely unclear what it has accomplished or where it
can or should go.
So I thought I'd ask.
All right. Since you ask, I'll answer. :-)
The truth is, I've found much of it frustratingly noisy and unproductive. I
mean, nothing changes here. How could it? Much of what is being brought into
question is thoroughly vetted and well-understood, as John very correctly
pointed out. I'd never advocate for a document which decided one way or the
other. Even the respective protagonists in the war for and against connection
caching seem to have some sense of the various pros and cons. If there's any
positive outcome, it's that I have questions I didn't have for a while now that
I'm going to need answers for in order to progress with my implementation. I
suppose that qualifies as future document material, but that's probably not the
kind you meant.
Perhaps this has merely been an extended consulting session to help a few
folk?
Given the amount of sage commentary has been posted, is there a document that
should be produced?
I think the question that needs answering most is not whether or not connection
caching is bad, but how we can best reduce the need for a compromise between
starting new client sessions and holding them open in the first place. The
answer has got to be a new SMTP extension, or pair of extensions, to do maximum
throughput sending on one connection and multi-message transaction advisory
mechanisms to support co-operation between bulk software and the MTA for
knowing the delivery load in advance, thus neutralising the discussion over
server administrative policy, port or connection slot exhaustion, client
selfishness, time to wait until shutdown, event-driven programming vs
process-based servers, OS wars and all the other nonsense. We need an improved
checkpointing facility. That's what we should do, I think.
Cheers,
Sabahattin
PS: The C10K document is inspired, and I'm a Unix person. My stuff is
event-driven. Just so you know. :-)