Dean" <dean@[spambuster]weany.com> wrote in message
news:402f552c$ XXXX@XXXXX.COM ...
It wouldn't do that anyway.
It will do that, though.
I understand that point already. What you need to understand is how Indy is
actually designed to work.
That does not matter, though. The *server's* endpoint of the connection is
still valid, and needs to be cleaned up separately from anything that
happens on the client side. If you pull the cable by hand, the underlying
socket stack ***will not recognize it right away***. The stack must time
itself out internally before it will recognize the connection is gone.
Until that happens, ***Indy thinks the connection is still active***,
because that is what the underlying socket stack itself still thinks. Even
if you read from or write to the socket after pulling the cable, the
underlying socket stack will buffer/queue the operation in hopes that the
connection comes back and it can then perform the operation normally. As a
result, the socket stack does not return any errors right away, and thus
Indy cannot detect that anything has happened to the connection, ***no
matter how much polling you do***. In your own code, you will just have to
use your own timeouts. If you are sending a ping-type packet periodically,
and you do not get any response in a timely fshion, just Disconnect() the
connection regardless of why the response is not received.
You as a person may have that information, but your software program does
not. It has no concept of why the response is not being received. Not
until the underlying socket stack itself times out internally and starts
reporting errors regarding the socket no longer being valid.
You already know how to do that, because it has been told to you several
times now - just Disconnect() the client socket on the server's end.
No, it does not. It will terminate. Disconnect() closed the server's
endpoint of the connection and then sets the connection's IOHandler to NULL.
Inside the actual thread, everytime the OnExecute event is reentered, any
operations you perform on the socket are dependant on the connection
remaining open and the IOHandler assigned. If you Disconnect() the socket,
then the next time the OnExecute event is triggered, your operation will
throw an exception since the socket is no longer valid. TIdPeerThread then
catches that exception internally and terminates itself as a result.
If the thread is not terminating correctly, then it has to be a problem with
your own code preventing it somehow. Left to its default behavior, it
*will* terminate properly.
Just call Disconnect(). That is the correct thing to do. If that is not
working for you, then please show your actual thread code, you are probably
doing something wrong with it.
It already does exactly that.