Board index » delphi » How to handle clients that immediatly disconnect

How to handle clients that immediatly disconnect


2005-01-17 09:29:30 PM
delphi187
My application has a TIdTCPServer. I have to serve clients that immediatly
close the connection after they receive the response from the server. Those
clients do not wait for the socket that they created with the server to be
closed by the server but rather close the socket them selves. The result is
that I always get a EIdSocketError "Connection reset by peer".
I guess that this happens because TIdTCPServer.DoExecute() checks the
"connected" state of the connection after it calls the assigned OnExecute.
Since my client always disconnects after the function that was assigned to
OnExecute finishes, the call to "connected" always raises that execption.
My problem is that I am not able to catch this execption.
To solve this problem I thought about creating a TIdMyTCPServer that
inherites from TIdTCPServer and to override the virtual DoExecute function
so that it would not check the "connected" state after the call to
OnExecute() and to have it return "false" to indicate that there is no
additional work for this socket:
function TIdMyTCPServer.DoExecute(AContext: TIdContext): Boolean;
begin
if Assigned(OnExecute) then OnExecute(AContext);
result := false;
end;
Is this the correct way to address the problem?
 
 

Re:How to handle clients that immediatly disconnect

"Offir Bakshitz" <nospam>writes
Quote
My application has a TIdTCPServer. I have to serve clients that
immediatly close the connection after they receive the response from
the server. Those clients do not wait for the socket that they created
with the server to be closed by the server but rather close the socket
them selves.
That is perfectly fine. Clients are allowed to do that, and servers are
allowed to let them do that.
Quote
The result is that I always get a EIdSocketError "Connection reset by
peer".
Did your clients send any actual data to the server? Did your server try to
send any actual data back to the client? Please show your actual code.
Quote
Since my client always disconnects after the function that was assigned
to OnExecute finishes, the call to "connected" always raises that
execption.
If your server has already sent its reply data to the client prior to the
disconnect, then your server is doing exactly what you are already asking
for. The fact that the client is disconnecting before the server does is
irrelevant. That is perfectly normal and allowable. I see no problem here.
Quote
My problem is that I am not able to catch this execption.
You are not supposed to. The server will catch it internally and clean up
the connection accordingly.
Quote
To solve this problem I thought about creating a TIdMyTCPServer
that inherites from TIdTCPServer and to override the virtual DoExecute
function so that it would not check the "connected" state after the call
to
OnExecute() and to have it return "false" to indicate that there is no
additional work for this socket:
Bad choice. The server is supposed to check the Connected property.
Quote
if Assigned(OnExecute) then OnExecute(AContext);
result := false;
That will throw an EIdNoExecuteSpecified exception.
Quote
Is this the correct way to address the problem?
No. For one thing, it is not a problem to begin with. What you have
described is perfectly normal for socket programming. The exception you are
seeing will get handled by the server internally.
If you expect your clients to always disconnect after receiving a response,
then just Disconnect() the client after sending the response to it. Don't
wait for the client to disconnect first. Both sides of the connection have
to close their respective sockets anyway, so it does not really matter the
order in which you do it.
Gambit