[Top] [All Lists]

Re: Mail Data termination

2011-08-20 18:36:21

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>

<Prev in Thread] Current Thread [Next in Thread>