 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Offir Bakshitz
Guest
|
 Posted: Mon Jan 17, 2005 1:29 pm Post subject: How to handle clients that immediatly disconnect |
 |
|
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?
|
|
| Back to top |
|
 |
Remy Lebeau (TeamB)
Guest
|
| Posted: Mon Jan 17, 2005 6:42 pm Post subject: Re: How to handle clients that immediatly disconnect |
|
|
"Offir Bakshitz" <nospam> wrote
| 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
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
