🚀 go-pugleaf

Thanks...  That helps clear up some ideas.

What I ended up doing was calling the function 'OnClientError' by push 
button and sending in Errors I wanted to occur that way so I can see if the 
way I was handling them would crash and burn.  Also the clients connected 
have about a 5 second timer if they do not get data they will close() and 
try and reconnect again.

I have a try {} and catch {} around 'SendBuf', but in some rare cases it 
will throw an "Invalid Integer" as the exception and have the program 
"Abnormally Terminated".  Also happens with the ErrorCode being set to zero 
on 'OnClientError' event. I could replicate this issue if I throw an 
exception on my own with now values associated.  Any ideas on that.

Thanks,
Justin



"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:44ad4c7c$1@newsgroups.borland.com...
>
> "Justin L Hudson" <justin.hudson@bepco.com> wrote in message
> news:44acf764$1@newsgroups.borland.com...
>
>> As a test I am manually disconnecting the client from the Ethernet card.
>
> That is your mistake then.  Pulling the cable is no guarantee that the OS
> will see the connection drop immediately.  In fact, on older systems, it 
> may
> not even see it at all.  Pulling the cable is an abnormal disconnect.
> Because momentarily network outages are common, especially on large
> networks, a socket has internal timeouts to deal with abnormal 
> disconnects.
> If the network goes out and then comes back quickly, and the socket can
> reestablish its previous connection internally, then the application never
> knows that the signal was momentarily lost.  On the other hand, if the
> network goes out and the socket can't reestablish itself, then it has to
> wait for its internal timeouts to elapse before the socket becomes
> invalidated.  The application will not see a disconnect until that time.
> Unfortunately, Microsoft's default timeouts are very lengthy - upwards of
> several hours!  You just have to wait it out, or else implement your own
> custom timeouts in your own code.  If no data is received on the socket 
> for
> a period of time, then just close the socket regardless of its actual 
> state.
> And if you are implementing your own custom protocol, you can add 
> keep-alive
> packets to it to force periodic data to be sent/received so that both
> parties can validate the connection.
>
>> What I am trying to do is replicate an issue out in the field where once
>> in a blue moon I will get an error while sending data to the clients 
>> which
>> causes an Exception Pointer with SendBuf().
>
> SendBuf() will only throw an exception if you do not have the 
> OnClientError
> event stop the exception by setting the ErrCode parameter to 0.  You 
> should
> also be looking at SendBuf()'s return value to know when an error occurs 
> so
> that you know to stop sending your data.
>
>> I think it is from trying to send out on a socket (client) that is no
> longer available.
>
> Very possibly.  There is no quarantee on the order in which events are
> triggered.  You may get an unexpected disconnect, or you may get an error.
> You have to handle them both.
>
>
> Gambit
>
>