Newsgroups : Borland : borland.public.delphi.internet.winsock : 2006 Jun : Re: IdTCPServer
| Subject: | Re: IdTCPServer |
| Posted by: | "brandon" (someo..@microsoft.com) |
| Date: | Fri, 9 Jun 2006 14:46:44 |
Got it...Sorry to seem sticky on the issue but... what about when the server
becomes unviable? Since I can not send a login request without a Socket
Error #0, will this not also block a keep alive / heartbeat from the client?
If it is in fact that the server.threads list is being blocked per Yorks
statement, would I not have an even larger issue with sending a heartbeat to
the server from the client? In that each heartbeat is going to generate a
socket #0 error the same as a log in request would.
>>>>York wrote:
>>>>If a dead client socket then the SendFrom may take a lot of time till
>>>> disconnect detected. This is going to block the other threads trying
to
>>>> access the server.threads list and also this is going to create a
delay
I am curious about the Socket Error #0 message. I have done a fair amount of
research and have not yet found anything that it relates to. It appears that
York is on to something that feels eerily close to what is happening to me.
"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:4489bd4d$1@newsgroups.borland.com...
>
> "brandon" <someone@microsoft.com> wrote in message
> news:4489aeea@newsgroups.borland.com...
>
>> Is it possible to poll the clients periodically to see if
>> they are alive, if not, then kill the thread gracefully.
>
> Since Indy uses blocking sockets, the only way to detect a dead socket is
> to
> read from, or write to, the socket and then check for an error.
>
> A better way to handle dead clients is to implement timeouts and
> keepalives
> in your own code. Make your client send a keep-alive command to the
> server
> periodically, and have the server respond to it. If the server does not
> receive the command in a given amount of time, just assume the client is
> dead (even if it really sn't) and disconnect the socket. If the client
> does
> not receive the response in a timely manner, then disconnect from the
> server
> and reconnect.
>
> This way, not only is the client actively telling the server "I'm still
> here, don't lose me" periodically, but it also serves as a way for the
> client to make sure the server is still alive as well.
>
>
> Gambit