From: Paul Smith [mailto:paul(_at_)pscs(_dot_)co(_dot_)uk]
Sent: Saturday, August 20, 2011 12:41 PM
Cc: Murray S. Kucherawy; ietf-smtp(_at_)imc(_dot_)org
Subject: Re: Mail Data termination
I'm with Hector on this. I really don't like the idea of a sender
keeping a connection open 'just in case'.
If it keeps it open for 10 seconds 'just in case', and no new mail
arrives so it has to close the connection, what has that achieved other
than extra load on the receiver? Why wouldn't it then say 'well, another
message may arrive in the next few seconds, so I'll keep it open just a
bit longer', and so on.
I don't see how keeping a connection open creates extra load in a modern
operating system. An open file descriptor is just an entry in a kernel table.
I've never seen an idle connection cause distress to a running system. Even
for an application that creates a complete subprocess to handle that idle
connection, the process would eventually get paged or swapped out in favour of
more active processes.
And if you somehow have so many open connections from clients that you can't
accept any more and another connection tries to arrive, select the one that's
been idle the longest, close it down (releasing resources), and accept the new
one. Or just generally trim your idle timeout down.
If the sender doesn't like closing and opening connections, then surely
it's just as beneficial for the sender to wait 10 seconds before
starting to send a message, then if another message to the same
destination arrives within that 10 seconds, it can batch them up without
adding unnecessary load to the receiver.
That's exactly how the connection cache works in some instances, depending on
whether or not the sender is configured to make an immediate delivery attempt,
or just wait for a queue run.
I'm really surprised there's so much sudden consternation about this feature
given how many MTAs have it, and the fact that it's been around for well over a
decade. Somehow, in that time, the sky hasn't fallen.