🚀 go-pugleaf

"Lesley Anne" <mspfila (dash) brl (at) yahoo (dot) com> wrote in message 
news:47f2cfe3@newsgroups.borland.com...

>   ErrorCode = 0;
>   Socket->Close();

What happens if you comment those out and just let OnError exit without 
changing anything?

> The event handlers all do fire until this error occurs.  The error
> event calls Socket->Close(), which should then give an OnDisconnect

It should.  Have you tried stepping through the TClientSocket source code in 
the debugger yet?

> but that never happens.  Neither does the Active property get set to false

Because seDisconnect is not being processed.

> Somehow Close appears not to be making it all the way
> through the Disconnect function.  If it's not due to the exit
> after that INVALID_SOCKET check

Inside the OnConnect event handler, what is the value of the 
TCustomWinSocket.SocketHandle property?  It should not be -1.  If it is not, 
then there is no way the INVALID_SOCKET check could be failing, since the 
SocketHandle cannot be reset to INVALID_SOCKET without going through 
seDisconnect first.

> then the only other things I can see that could be happening is
> that either the try block in Disconnect somehow isn't making it
> past the first few lines, and is jumping out to its finally block
> before reaching the Event call

Once INVALID_SOCKET is ruled out. The only way that can be happening is if 
an exception is being raised.  The debugger can tell you that.

> Also, in addition to that call to Socket->Close in the OnError handler 
> itself, I also have the ReconnectTimer (shown at the end of my first post 
> in this thread) which is periodically attempting
>         BEClientSocket->Close();
>         BEClientSocket->Open();
> for as long as the socket remains in this error state (as shown by that 
> indicator being set to clRed).  None of these Close or Open attempts
> work either.  Once the socket gets this error, neither OnConnect nor
> OnDisconnect events occur again.  Active remains true, but there is
> no communication with the server app (which times out after a while,
> closing its side of the connection).

Have you tried disabling that timer altogether until we figure out why the 
TClientSocket is in such a bad state?  Don't even enable it at all.  Take 
out everything you can from your code so you have the most bare-bones 
reproducable scenerio to get into the error state.

> The only other thing I know right now is that the problem occurs around
> midnight when the server closes the connection for a few moments to do
> some other processing.  When it re-opens and the clients reconnect (or
> try to) that's when the remote client gets this error.

You did not say that before.  That is an important detail to know.  The 
server may be killing the socket endpoints of existing clients incorrectly, 
invaliding TClientSocket's endpoint before you can send any data to it. 
That might explain the WSAENOTSOCK error, but that still does not explain 
how TClientSocket could be tracking it so badly.


Gambit