Well written.
Pavel Kankovsky wrote:
> Hmm...RSET needs one roundtrip (C: RSET, S: OK). A new SMTP connection
> needs 3 roundtrips: 1. C:TCP(SYN), S:TCP(SYN+ACK), 2. C:TCP(ACK), S:server
> hello, 3. C:HELO, S:OK. Moreover a typical TCP implementation will open
> every new connection with most parameters (such as rtt, window, mtu) set
> to some default values and it takes a while to adjust them. Your claim
> (less roundtrips, better performance) is at least misleading...what is
> meant by "roundtrips" in that context anyway?
And I'm very glad you brought up "round trips" because I'm getting the feeling
that not very many people are considering how TCP works in an IP context vs.
how SMTP works over TCP. That is to say, you gain quite a bit initially by
opening parallel TCP connections, but opening them in sequence (closing one,
opening a new one) is inherently expensive. Cutting down the number of
open+closes is a 'good thing'.
> The real reasons why qmail-style multiple connections are very likely to
> outperform sendmail-or-whatever-style single connections are:
Comments given once ... read them in the list archives ... cut for brevity.
> This is similar to the
> "communistic" behaviour of the traditional unix CPU scheduler: the more
> processes you run, the more CPU time you get...at the other user's
> expense. Today, it pays off to be aggressive (OTOH, I am not sure it
> will pay off tomorrow in the more QoS-aware Internet).
QoS is something I spend quite a bit of time working with, especially with VPN
links I'm running and trying to make the most of clients' access bandwidth when
running multiple 56k analog modems (2 or 3 aggregate).
