🚀 go-pugleaf

"Remy Lebeau (TeamB)" wrote in message 
news:47f16f19$1@newsgroups.borland.com...
>
> "Lesley Anne" wrote in message news:47f16766$1@newsgroups.borland.com...
>
> > Client gets OnError event with: ErrorEvent == eeSend,
> > ErrorCode == 10038 (WSAENOTSOCK)
>
> Is the connection passing through a router or firewall?

Yes.  In fact, we have two instances of the client application.  The local 
one which only passes through a switch doesn't have this problem.  The other 
one which passes through a couple of routers with firewalls and a 
long-distance circuit is the one where the problem occurs.  This certainly 
sounds like the initial source of the problem is something getting dropped 
by the network, and some of my co-workers who are more familiar than I am 
with the routers and firewalls are looking into that.  In the meantime, I'm 
trying to make the software more robust and tolerant of network glitches.


> > Within the OnError event handler, Client calls Socket->Close()
> > No OnDisconnect events occur
>
> It has to be.  TCustomWinSocket.Close() fires the OnDisconnect event 
> handler directly before then destroying the socket handle.

But it doesn't call the event handler if the socket is invalid.  Would it be 
invalid in the case of a WSAENOTSOCK error?


> > and Client remains Active.
>
> The only way it can be active after Close() is called is if the 
> seDisconnect notification is never being processed at all.

This goes back to the question just above.  Would we have an INVALID_SOCKET 
when some network glitch causes a connection to get WSAENOTSOCK errors 
(after becoming Active and getting an OnConnect event)?  In that case, the 
seDisconnect notification wouldn't be processed, since if the Socket is 
INVALID_SOCKET, then the Disconnect function exits early, before the 
seDisconnect notification.  Given the symptoms I'm seeing, it looks like 
that may be what's happening.  If I have an invalid socket, how do I clean 
it up and get my TClientSocket component back to its normal disconnected 
non-Active state?


> For one thing, you must look at the return value of SendText() or 
> SendBuf() in order to know if the entire string was sent at all.

But in non-blocking mode, I don't expect it to have already been sent.  I 
don't have time to let my main thread wait while the send actually occurs so 
that it can see whether it was successful or not.  (That's what blocking 
mode would be for, but it requires a separate thread if I don't want my main 
VCL thread to be waiting for it.)


> If it is not, and the result is -1 without an OnError event being 
> triggered, then you must wait for the OnWrite event to fire and then 
> re-sent the same data again before then sending any subsequent new data.

Maybe I'm misunderstanding that explanation, but it sounds like it's 
effectively making the "non-blocking" mode blocking.  In fact it's a 
particularly convoluted blocking in which one event has to wait for several 
others before it can continue.  There's the initial event that has something 
it wants to send, but it has to wait for separately triggered OnError and 
OnWrite events to occur (or not occur) before it can continue, and it has to 
somehow communicate with those other events, which it is neither calling nor 
being called by.  I don't really understand how all of these get 
coordinated.


> You are likely trying to send the data too early.  Between when Open() is 
> called and the OnConnect event is fired, you cannot send data to the 
> socket. It is not ready yet.  You must wait for the OnConnect event first.

OK, that makes sense.  I saw where you cautioned someone else to check 
Connected rather than Active.  I can try changing that.  Would Connected 
give me a more reliable indication of when it's ready?  (I am seeing the 
OnError event handler /after/ the OnConnect event handler, but maybe it's 
possible that the SendText call which led to the error happened sooner, and 
before the OnConnect.)


> > And why does it never get the OnDisconnect event?
>
> Are you assigning a handler to the client's OnSocketEvent event, by 
> chance?

No.  Just the OnConnect, OnDisconnect, and OnError events (all from the 
TCustomSocket layer of the inheritance if I understand it correctly).