On 22.08.2011 15:00, Paul Smith wrote:
On 22/08/2011 13:46, John C Klensin wrote:
gather up everything you can find and send it as part of the same
connection and, especially if the connection took several tries to
establish, maybe keep it open for short while to see if anything else
can be pushed through it
That confirms that the idle time ought to be proportional to the time
necessary for establishing and terminating the connection (that I called
overhead in a previous message). The proportionality factor can take into
account statistical prediction from recent history. It should be at least as
long as to allow a local busy mailer to actually submit the next message, and
may be further constrained by ephemeral ports/TIME_WAIT considerations.
However, what we mean by "idle" was not specified clearly. The acceptance of
the current message by the server doesn't seem to be relevant, thus we can as
well consider "idle" the time taken by the receiver to run any mail filters
before replying. Consider the following SMTP-fictional snippet:
C: ...blah blah the end of the message.
C: <CRLF>.<CRLF>
S: 100 Hold on.
C: Yes, please take your time.
... this is some idle time...
S: 250 Ok, message queued.
... this is more idle time...
C: QUIT
I still think that 'pre-queuing' rather than 'post-waiting' is more community
spirited
Maybe. But at pre-queuing time a sender doesn't really know which MXes will
be reachable. Vanity domains may resolve to the same MX, an MX may have
multiple IP addresses, a domain may sport multiple primary MXes, ...
In that environment, the strategy is not only not antisocial, it is hugely
beneficial, not just to the sender but to the receiver and the
users/mailboxes it supports.
Not if it prevents other senders getting their messages through while the
first sender was sitting with an idle connection using up the connection
quota.
The queueing model implied by SMTP provides for servicing the current client
for as many transactions as it wishes. Other senders, who are unable to
connect to their target MX, can be considered to form a virtual queue.
Servers shape their queues according to their policies and configurations,
including load limits, max open connections [per IP| class], {white| gray|
black}listing, and any such means.
A server can disconnect a client, but cannot invite it to wait idle for a
while, nor disclose its current idea of optimal waiting factor.
Keeping connections open 'too long' is fine if you assume that the receiver
has an unlimited number of connections available. Once you accept that this
is a limited resource in many cases, then it becomes a much nastier thing to
do. If there's an unlimited number of connections, then an idle connection
costs the receiver nothing. If the receiver is limited to, say, 10
simultaneous connections, then the idle connection costs the receiver 10% of
its capacity.
What if the sender is also limited to 10 connections? It is sacrificing its
chance to deliver messages destined to other MXes for the sake of the
currently connected server's optimization. Such clients altruistically
relieve servers from repeating unneeded operations, don't they? :-/