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