On Jan 16, 2007, at 02:49, Arno Garrels wrote:
> When the response to the Quit command is received the connection
> (may) still be alive. So watch both, whether Quit response has been
> received as well as the SessionClose event. Call connect only
> after the session has been closed.
> Don't start a loop directly from an event handler but post a custom
> message to some Window, in it's message handler start the next loop.
You could, in fact, re-use the connection if the next message is to be
sent through the same server. All you have to do is, after the DATA
command is completed and the server acknowledges receipt, check
SmtpCli.Connected, if you are still connected then reset your
state-machine to start the cycle fromthe MAIL FROM command. Some
servers required a "reset" (RSET) command be sent to reset state, and
it doesn't hurt to send it anyway. The important thing is to check the
connection, because something may have happened -- and indeed, some
servers have anti-spamming filters that will kick you out after
receiving DATA that they determine is spam, and some won't allow you to
re-send after one message. So the algorithm would be something like:
1. Connect
2. HELO
3. MAIL FROM
4. RCPT TO
5. DATA
6. If connected:
6.a (yes) RSET then back to 3
7. QUIT
8. back to 1
Of course, you should check for errors after each step (in
OnRequestDone, before changing states). Keep in mind that some errors
are recoverable (transient: 400+), some errors are not (non-transient:
500+), and some are somewhere in between (like RCPT warnings, etc).
Recoverable errors allow you to try again, or require a RSET and start
from step 3, while non-transient errors require closing the connection
and starting from scratch. If you are sending general messages to
strange servers "in the wild" it gets pretty complicated, specially
when you factor in all the non-RFC-compliant servers; but if your
application is of limited purpose, sending using the same server all
the time, the errors and issues that may occur are predictable and
substantially less.
Building this logic in a simple state-machine using OnRequestDone makes
it fairly easy to make your application powerful and efficient -- the
reason we always push for the use of async methods.
dZ.
--
DZ-Jay [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
