For your #1: this would be similar to the Linux kernel approach to DMA on hard
drives ... enable by default, except on those drives we have in database of broken
drives.
As for #2 and #3: this adds overhead, of course, but could inherently reduce
overhead down the road, as long as the algorithm is simple. Something like a
simple:
(pseudo:)
if (hosts[current].connections < hosts[current].max_connections)
{
/* ... open connection ...
... read response ...
... record response latency as current_latency ... */
if (response_val == 421
|| current_latency > best_latency * (1 + latency_percentage))
{
hosts[current].max_connections = hosts[current].connections;
/* could be connections -1 but this will keep trying to up the # */
} else {
best_latency = min(best_latency, current_latency);
/* ... do delivery ... */
}
}
I hope this satisfies someone ... :-P
"John R. Levine" wrote:
> I've been thinking for quite a while of some sort of hack to qmail to
> do remote load management, the idea being that we want to open almost
> but not quite enough connections to each remote system to make the
> remote fall over.
>
> Possibilities for guessing the appropriate limit per remote might include:
>
> - sniff the SMTP banner for known lame MTAs
>
> - measure the round trip time, for the response to HELO, stop connecting
> when it becomes "too much", either an absolute limit or N times more than
> it used to be
>
> - pay more attention to "421 come back later" type messages
