> qmail's current behaviour is similar to netscape's behaviour where it
> opens multiple tcp connections to suck down multiple images at the same time.
In both cases, parallel connections produce results for the user as
quickly as possible.
> But as has been shown by the W3C
> <http://www.w3.org/pub/WWW/Protocols/HTTP/Performance/Pipeline.html>,
> pipelined connections are far more efficient on bandwidth.
But, gee, most servers don't support pipelined connections.
Nor compression, which is what saves most of the bandwidth.
> Pipelining is available as an extension to SMTP.
So is compression, with XLZW. So what? Are you trying to deliver mail in
a fantasy world, or in the real world?
Anyway, SMTP ``pipelining'' is nowhere near as effective as HTTP
pipelining---it doesn't do anything about the per-message RTTs. Try
QMTP, or UUCP, if you really want to reduce latency.
> So it's reasonable to think that
> it wouldn't be hard to put pipelining into the major MTAs
sendmail forks after MAIL FROM. This prevents pipelining.
> At any rate, every time this topic comes up the claim is made that qmail's
> approach is superior regardless of the waste of bandwidth.
The bandwidth loss from parallel connections is wiped out by bandwidth
gains in other areas.
Anyway, here's a specific latency figure: qmail reportedly completed
28000 deliveries around the world in half an hour from a single PC.
> A simplistic approach such as sorting the recipient list by domain and using
> pipelining for recipients at the same domain is likely to be faster than
> what qmail does now.
I'm really not interested in listening to further uninformed speculation
on this topic.
---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html
> opens multiple tcp connections to suck down multiple images at the same time.
In both cases, parallel connections produce results for the user as
quickly as possible.
> But as has been shown by the W3C
> <http://www.w3.org/pub/WWW/Protocols/HTTP/Performance/Pipeline.html>,
> pipelined connections are far more efficient on bandwidth.
But, gee, most servers don't support pipelined connections.
Nor compression, which is what saves most of the bandwidth.
> Pipelining is available as an extension to SMTP.
So is compression, with XLZW. So what? Are you trying to deliver mail in
a fantasy world, or in the real world?
Anyway, SMTP ``pipelining'' is nowhere near as effective as HTTP
pipelining---it doesn't do anything about the per-message RTTs. Try
QMTP, or UUCP, if you really want to reduce latency.
> So it's reasonable to think that
> it wouldn't be hard to put pipelining into the major MTAs
sendmail forks after MAIL FROM. This prevents pipelining.
> At any rate, every time this topic comes up the claim is made that qmail's
> approach is superior regardless of the waste of bandwidth.
The bandwidth loss from parallel connections is wiped out by bandwidth
gains in other areas.
Anyway, here's a specific latency figure: qmail reportedly completed
28000 deliveries around the world in half an hour from a single PC.
> A simplistic approach such as sorting the recipient list by domain and using
> pipelining for recipients at the same domain is likely to be faster than
> what qmail does now.
I'm really not interested in listening to further uninformed speculation
on this topic.
---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html