On Sat, 2011-08-20, Paul Smith wrote:
On 18/08/2011 22:56, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
But more to the point, you're talking about very different time
regimes here. Caching a connection for anything even close to five
minutes is almost certainly counterproductive - SMTP connection
establishment isn't *that* difficult. But holding on to a connection
for just a few seconds can be quite beneficial for systems handling
high volumes of mail.
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.
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.
It just seems selfish for the sender to say 'I'm so important that I'm
going to hog one of the receiver's channels just in case someone else
wants to send a message to them, so the sender doesn't have to wait a
few seconds longer'.
It seems to me that the measure is NOT the "number of clients"
but rather the number of messages handled.
Each client will have a certain number of messages to transmit to
the receiver over a time period, regardless of the number of
sessions used. When a client saves a session teardown and
reestablishment by delaying QUIT, so does the receiver. So it
would seem that a delay on the order of that time IS warranted. I
don't have a good feel for the amount of that overhead, but I
would guess that a second or two is reasonable and ten seconds is
approaching too long.
--
Bill McQuillan <McQuilWP(_at_)pobox(_dot_)com>