On Jul 30, 2006, at 12:26, Max Terentiev wrote:
> My program MUST call Abort() because it's email checker. It's interrupt
> connection after Success of RCPT command.
DO NOT call Abort(), call QUIT!! Then OnRequestDone is triggered when
it finishes and the connection is closed cleanly. Abort() just shuts
down the socket unconditionally, which is not the best way to handle
TCP/IP connections -- it does not trigger an event and it does not set
an error condition, therefore the component is left in a completely
unreliable state. This is intended for emergency situations, like when
the user shutsdown the application or the machine and you don't care
when or if the connection was closed, you just want to free the
resources immediately and not wait for any state change. The sysadmin
may even find it suspicious that TCP/IP connections keep getting
dropped from the same source without reason.
The reason why you should not use Abort() in your particular case is
that you want to reuse the component to connect to the POP3 server
after connecting to the SMTP, right? In that case you *NEED* to know
when the connection was closed completely and the component is reset
and ready for a new connection (which is your original question). Why
invent some new message handler for the Abort() method, which was never
intended for this use, when you can use the perfectly adequate Quit()
method, which will close the connection gracefully, and even notify you
when it is done and ready via the OnRequestDone event. Abort will not
close the connection faster, it will just reset the state of the
component faster -- without regard of the current underlying socket
state. Besides, why would you care for the speed of the disconnect,
when you still need to wait for the component to actually close and
reset state?
dZ.
--
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
