David!
I think people just get annoyed by pull talk so I have skipped that... This
message is free from all pull arguments...
As to SMTP inefficiences:
I guess You and I aggree that it is a good thing to keep memory usage down
to have a fast server less vulnerable to DoS attacks. However we do not
count the memory the same way.
You and SMTP want to send small bits of information and catch an error as
soon as possible. The general idea is: why send everything including a huge
manuscript as an attatchment only to learn that the recipient is unknown! I
aggree. It would probably not be efficient.
However when discussing memory usage in server to server communication you
must consider one other factor: the time the the data remains in the memory.
SMTP has something like at least 12 trips over the Internet (for a
successful mail).
The thing which takes time in SMTP are the network trips. I have no figures
but say an ordinary mail (without attatchments) in SMTP takes 1 second to
send and that it uses an avarage of 0,4Kb. Then 1Mb will last for 2600
mails. If all is sent at once a mail could take say 1,5Kb and be completed
in 0,1 seconds. Then 1Mb will last for 6800 mails. I repeat: my figures are
just estimations, but any textbook on server to server communication in
DCOM, CORBA, Web Services etc stress the fact that network trips waste
server resources. Web Services are actually designed for single
request-response solutions (even if sessions, cache and similar technologies
are available). Any mail without an attatchment is so small that I cannot
see why what is true in more complex programs would not be true in SMTP.
I realize attatchements are a problem so I would suggest:
A Without attatchment
1. Send all data but the attatchment + a boolean signaling no attatchemnet
2 Let the server go through the data according to SMTP protocol and return
the first error message. Otherwise return OK
B With attatchment
1 Send all data but the attatchment + a boolean signaling attatchment
2 Let the server go through the data according to SMTP protocol and return
the first error message. Otherwise return OK
3 Send the attatchment
4 Return OK or error message
I.e. I just minimize the network trips and pack the data in larger chunks
and let the server go through the chunk according to SMTP and return an
error as soon as one is encountered. The CPU will not have to handle several
OK messages and several calls.
Again, I cannot understand why what is common knowledge in COM, DCOM, Web
Services and CORBA would not apply to mail servers. It is all a matter of
processing data and handling network trips. If anyone could explain the
difference I will have learnt something essential.
/DK
----- Original Message -----
From: "David Maxwell" <david(_at_)crlf(_dot_)net>
To: "Dag Kihlman" <dag(_dot_)kihlman(_at_)htu(_dot_)se>
Cc: <asrg(_at_)ietf(_dot_)org>; <scrosby(_at_)cs(_dot_)rice(_dot_)edu>
Sent: Monday, December 01, 2003 6:16 PM
Subject: Re: [Asrg] Re: 6. Proposals - Pull System (revisited)
On Sat, Nov 29, 2003 at 12:44:33PM +0100, Dag Kihlman wrote:
I agree with Scott: people seem unwilling to make hard choices. The SMTP
protocol is old, ideal for spammers and inefficient. Any textbook
covering
Could you point out an 'innefficiency' in SMTP more specifically,
please?
That's one fault I don't see SMTP as having - unless you're saying that
all the spam clogging the pipes makes SMTP inefficient... not quite the
normal application of that word.
communication between tiers have one basic rule: avoid communication as
much
as possible. The ideal solution is to send all at once and if necessary
receive a receipt containing the data you want or an error message. Any
new
standard ought to be built on this simple principle. Why HELO? Send
everything and let the receiving server go through the sender's data
returning the appropriate answer.
That sounds like a contradiction to me: "avoid communication" AND "Send
everything"
Steps like HELO will continue to be useful in protocols for the same
reason the 3 way handshake is critical to TCP. Before you commit
significant resources to a session, you need to sanity check it. Failure
to do so leaves the door open to DoS attacks.
--
David Maxwell, david(_at_)vex(_dot_)net|david(_at_)maxwell(_dot_)net -->
Mastery of UNIX, like
mastery of language, offers real freedom. The price of freedom is always
dear,
but there's no substitute. Personally, I'd rather pay for my freedom than
live
in a bitmapped, pop-up-happy dungeon like NT. - Thomas Scoville
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg