🚀 go-pugleaf

"Justin L Hudson" <justin.hudson@bepco.com> wrote in message
news:44ac0064@newsgroups.borland.com...

> Is there a way to make the TimeOut for a 'OnClientDisconnect'
> to come up faster?

No.

> The situation is, that when I disconnect a Client from the
> ServerSocket, it takes a good couple of seconds before the
> 'OnClientDisconnect' is thrown.

Are you using the TServerSocket in non-blocking mode?  If so, then the speed
of the component is directly related to the speed in which your message
queue can process new messages.  Non-blocking sockets use window messages
internally for their asynchronous notifications.  If it is taking so long
for the event to trigger, then either 1) the message queue is slow, or 2)
the OS itself is not detecting the disconnect right away to begin with.  How
EXACTLY are you disconnecting the client?


Gambit

It is non-blocking. As a test I am manually disconnecting the client from 
the Ethernet card.  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().  I think it is 
from trying to send out on a socket (client) that is no longer available.

Any insights would be appreciated.

Thanks,

Justin

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:44ac15e3$1@newsgroups.borland.com...
>
> "Justin L Hudson" <justin.hudson@bepco.com> wrote in message
> news:44ac0064@newsgroups.borland.com...
>
>> Is there a way to make the TimeOut for a 'OnClientDisconnect'
>> to come up faster?
>
> No.
>
>> The situation is, that when I disconnect a Client from the
>> ServerSocket, it takes a good couple of seconds before the
>> 'OnClientDisconnect' is thrown.
>
> Are you using the TServerSocket in non-blocking mode?  If so, then the 
> speed
> of the component is directly related to the speed in which your message
> queue can process new messages.  Non-blocking sockets use window messages
> internally for their asynchronous notifications.  If it is taking so long
> for the event to trigger, then either 1) the message queue is slow, or 2)
> the OS itself is not detecting the disconnect right away to begin with. 
> How
> EXACTLY are you disconnecting the client?
>
>
> Gambit
>
> 

"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

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
>
> 

"Justin L Hudson" <justin.hudson@bepco.com> wrote in message
news:44ad61ce$1@newsgroups.borland.com...

> Also the clients connected have about a 5 second timer if they
> do not get data they will close() and try and reconnect again.

You should implement that scheme inside your server code as well.  If the
server does not receive data from a client after while, then disconnect the
client.  Then make your clients send data periodically to keep the
connection alive.

> I have a try {} and catch {} around 'SendBuf', but in some rare
> cases it will throw an "Invalid Integer" as the exception

SendBuf() does not throw that exception.  You probably passed in an invalid
memory block.  What is the actual exception class type and completely
Message?  What does your sending code look like?

> Also happens with the ErrorCode being set to zero on 'OnClientError'
event.

All the more reason to suspect that the exception is occuring outside of the
socket altogether.


Gambit

It is a pointer to data in another thread that could be getting changed 
somehow.  Would have to look deeper.  I have error log loaded in the program 
and it catches exception "EInvalidPointer", but sometimes also catches 
"ESocketError - Only one usage of each socket address is normally 
permitted", but think I have handled that one now.  Good to know SendBuf 
would not be throwing the excpection, so can focus on other reasons pointer 
might be getting messed up.

I would agree with you that the socket is no longer the issue main, thanks 
for all the help.

Justin


"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:44ad7444$1@newsgroups.borland.com...
>
> "Justin L Hudson" <justin.hudson@bepco.com> wrote in message
> news:44ad61ce$1@newsgroups.borland.com...
>
>> Also the clients connected have about a 5 second timer if they
>> do not get data they will close() and try and reconnect again.
>
> You should implement that scheme inside your server code as well.  If the
> server does not receive data from a client after while, then disconnect 
> the
> client.  Then make your clients send data periodically to keep the
> connection alive.
>
>> I have a try {} and catch {} around 'SendBuf', but in some rare
>> cases it will throw an "Invalid Integer" as the exception
>
> SendBuf() does not throw that exception.  You probably passed in an 
> invalid
> memory block.  What is the actual exception class type and completely
> Message?  What does your sending code look like?
>
>> Also happens with the ErrorCode being set to zero on 'OnClientError'
> event.
>
> All the more reason to suspect that the exception is occuring outside of 
> the
> socket altogether.
>
>
> Gambit
>
> 

"Justin L Hudson" <justin.hudson@bepco.com> wrote in message
news:44b24787$1@newsgroups.borland.com...

> It is a pointer to data in another thread that could be getting changed
> somehow.

That is very likely.

> I have error log loaded in the program and it catches exception
"EInvalidPointer"

All the more reason to think that you are corrupting the data that you are
trying to send.

> sometimes also catches "ESocketError - Only one usage of each
> socket address is normally permitted"

That is WSAEADDRINUSE.  Typically, that only happens if you are trying to
bind a new socket to an IP/Port that is already in use by another socket.


Gambit

I can definitely agree with this comment, you can get all sorts of different 
behaviour disconnecting the cables out of PCs, Routers, Hubs, etc.  And then 
different scenarios again depending on with version of OS you use.

We've just been evaluating a network emulator to do more realistic network 
testing.  It costs about �20K GBP though!  We've found quite a few things 
wrong with some of our products in the few days we've had it.  I'm hoping we 
can test better in house rather than finding out the hard way on 'live' 
customer sites!

http://www.packetstorm.com/

Paul.


"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:44ad4c7c$1@newsgroups.borland.com...
>
> 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.