Board index » cppbuilder » ESocketError 'Asynchronous socket error 10053'

2004-01-20 08:01:46 AM
cppbuilder77
Again using a TServerSocket with ServerType = stNonBocking.
The server program is running and then all of a sudden I get this message
which popups in the de{*word*81}
Project TestServer.exe raised exception class ESocketError with message
'Asynchronous socket error 10053'. Process stopped. Use Step or Run to
continue.
I then hit ok. The de{*word*81} stops on the line showin below
WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
try
{
Application->Initialize();
Application->CreateForm(__classid(TfrmMain), &frmMain);
Application->Run();
} //****** DE{*word*81} STOPS HERE ****
catch (Exception &exception)
{
//*** DE{*word*81} DOES NOT GET TO THIS CODE
Application->ShowException(&exception);
}
return 0;
}
I hit F7 to step and then nothing happens.
I click on the TestServer.exe on the task bar it shows that "Asynchronous
socket error 10053 again.
What is this exception and why is not being caught by Catch(Exception& e).
Do I need to be catching a ESocketError
Do I need to be catching that in my OnClientError event code and setting
ErrorCode = 0 when this error occurs?
 

It apears as though its eeDisconnect which has this in the help file. " An
error occurred when trying to close a connection."
I was always setting my ErrorCode to 0 that must be why I never saw this
error before. After redesigning my server I didn't put this in there. So
for now I'm just setting it to 0 when I get an eeDisconnect in my
OnClientError event handler.
Should I be calling Socket->Close() when I get this exception?
 

"JunkMail" < XXXX@XXXXX.COM >wrote in message
(10053)
Software caused connection abort.
An established connection was aborted by the software in your host
machine, possibly due to a data transmission timeout or protocol error.
Gambit
 

{smallsort}

"JunkMail" < XXXX@XXXXX.COM >wrote in message
place.
Gambit
 

"Remy Lebeau (TeamB)" < XXXX@XXXXX.COM >wrote in message
until I try to send a message to that client again. So I'm geting the
OnClientError event with an eeDisconnect and then I don't get the
OnClientDisconnect until I try to send them something.
so I was thinking inside of the OnClientError event if I receive an
eeDisconnect error then I do this
if(Socket->Connected)
Socket->Close();
That way my OnClientDisconnet gets called before hand and I'll never try to
send them stuff again.
Will that cause problems?
 

"JunkMail" < XXXX@XXXXX.COM >wrote in message
As soon as the OnDisconnect event returns, you have no more guarantees that
the socket is valid anymore. The OnDisconnect event is the last time the
socket is still valid before being closed. Also, once a socket is
disconnected, there won't be anymore events for that socket, other than
possibly the OnError event if you try to access an invalid socket later on.
setup to Disconnect() the socket as soon as the error occurs. Also, the
fact that you are even getting an OnError event with eeDisconnect specified
in the first place should tell you something that you need to pay attention
to - the socket was being disconnected, and an error occured during that
operation. Disconnects cannot be aborted prematurely - once started, the
socket is no longer a valid entity. So stop using the socket, it was being
shut down for a reason. Continuing to use a disconnected socket will only
lead to more errors.
the first place. There is no point in closing a socket that is already
being closed.
Gambit
 

Let me restate what is happening...i'm not sure I made myself clear enough.
The first even that is triggered is the OnClientError event. In this event
I get the eeDisconnect error. The OnClientDisconnect event is not triggered
(according to my break points).
The next time I try to send the client some data...then the
OnClientDisconnect event is triggered. You can duplicate this by simply
having a client connect and then ending the process of the client. After
ending the process of the client the OnClientError is triggered...but no
OnClientDisconnect is triggered.
I've hade made extra precautions to not use the socket after the
OnClientDisconnect event is triggered...but since this is not triggered
before the OnClientError with eeDisconnect error I'm wondering if I should
close the socket there so that my code that sets variables in my class to
not use the socket anymore occurs before I actually send any data to them.
 

"Junk Mail" < XXXX@XXXXX.COM >wrote in message
abnormally. The socket is gone at that point, you can't do anything more
with it.
By default, it is not supposed to be. However, if you set the ErrorCode
parameter to 0 in the OnError event, then the default handling for closure
events will then trigger the OnDisconnect event afterwards.
abnormal, unintentional, unnegotiated disconnect occurs, such as the one you
describe, the socket stack *DOES NOT* know about it right away. It can't
know, there is no kind of notifications sent out in that scenerio. As such,
there is no way a VCL component, be it TServerSocket, TClientSocket, or any
other kind of socket implementation, can trigger any kind of OnDisconnect
event, because it simply has no way of knowing a disconnect occured in the
first place. That is simply not how sockets are meant to work in general.
Disconnects have to controlled, they have to be negotiated and agreed on, in
order for either end of the connection to know immediately that the
connection is going away so it can act accordingly. TCP is specifically
designed to allow temporary outages on network connections. And it is
because of that "feature" that requires the socket stack to wait for a
period of time before it can detect abnormally lost connections before it
starts failing operations. That is why you don't see errors occur until you
actually try explitically to access the socket after it has been
disconnected prematurely.
Gambit
 

Socket->Close() method...but instead I should copy the code in my
OnClientDisconnect event handler and paste it into the code in the
OnClientError event for the specific error of eeDisconnect?
 

Junk Mail wrote:
Actually I do not only do that for eeDicconnect but
for every ErrorCode for every OnError triggered.
Hans.
 

"Junk Mail" < XXXX@XXXXX.COM >wrote in message
event handlers can then call when needed?
Gambit
 

 

"Hans Galema" < XXXX@XXXXX.COM >wrote in message
comes to mind...I also use to close the socket in the OnClientError event
from every every. Problem was when my read event triggered the
OnClientError. I had several ReceiveBufs in the OnClientReadEvent and if
the first one triggered an error I would get an access violation error on
the second. I don't recall if I had the ReceiveBufs in try catches though.
At any rate my design should handle this more gracefully as long as I call
the code in the OnClientDisconnect...whether I actually call the
Socket->Close or just call a method with the code inside of the
OnClientDisconnect this problem should be taken care of...hopefully I
haven't fully tested yet :)
 

"JunkMail" < XXXX@XXXXX.COM >wrote in message
sure that it wasn't reporting an error as well? Just because there is an
OnError event available does not negate the need to check return values as
well. You should always be doing that.
Gambit
 

"JunkMail" < XXXX@XXXXX.COM >wrote in message
"code reuse" that you should keep in mind :-) It is the basis for OOP in
the first place.
Gambit