"PeaShooter_OMO" <jacquesvdm@homemail.co.za> wrote in message
news:462513de@newsgroups.borland.com...
> Abnormal but possible. Its the world of Windows.
I know it is possible. That is not the point I was trying to make. A
socket can't detect an abnormal disconnect until it times out
internally, which unfortunately on Windows can be upwards of several
hours. If a client connects to a server and then the server goes down
unexpectedly, the client won't know right away. On the other hand, if
a client goes down unexpectedly, the server won't know right away.
Either way, you need to implement some kind of system in your
communication protocol for both sides to detect when the other side
has become idle and is no longer responding, so that the socket can be
closed and released gracefully in a timely manner on the side that is
still running.
If you have control over the protocol design, then the easiest way to
implement that is to have the server keep track of when each client
last sent any data to the server, and then disconnect any clients who
are idle for too long a period of time. Then require the clients to
send data to the server periodically for as long as they want to stay
connected, and wait for a reply. This way, the server can disconnect
idle clients, and clients can disconnect from unresponsible servers.
> I have written a ListenerThread like you advised. And I think
> its pretty thorough.
It is not thorough.
> I test the connection when I want to Send something. When
> I test the connection I do the following:
You should not be doing that. Indy already does that internally for
you. Just send normally, and then catch any error that may occur.
> This gives an exception in my case if the app was ended by ending
the process
Not right away, it doesn't, because the OS doesn't keep track of that
on most systems. Killing off the server is not guaranteed to notify
clients right away, so they have to wait until they timeout internally
on their ends first before any errors are reported by their OS. That
is simply the nature of how sockets work in general, because of the
way networks are designed, in particular in how they handle outages
and internal reconnects.
Gambit
