Article View: borland.public.cppbuilder.internet.socket
Article #2249Re: Borland C++ 5 TServerSocket TimeOut
From: Remy Lebeau (TeamB)
Date: Thu, 06 Jul 2006 17:46
Date: Thu, 06 Jul 2006 17:46
43 lines
3155 bytes
3155 bytes
"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
Technical Details
Message-ID:
<44ad4c7c$1@newsgroups.borland.com>Path:
arc1-ca.pugleaf.net!g2news2.google.com!news2.google.com!news.germany.com!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mailReferences:
<44ac0064@newsgroups.borland.com> <44ac15e3$1@newsgroups.borland.com> <44acf764$1@newsgroups.borland.com>Show Full Headers
Complete Article Headers
X-Google-Thread: 11508e,43b3cea56f3f8096 X-Google-Attributes: gid11508e,public X-Google-Language: ENGLISH,ASCII-7-bit From: "Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> Newsgroups: borland.public.cppbuilder.internet.socket References: <44ac0064@newsgroups.borland.com> <44ac15e3$1@newsgroups.borland.com> <44acf764$1@newsgroups.borland.com> Subject: Re: Borland C++ 5 TServerSocket TimeOut Date: Thu, 6 Jul 2006 10:46:27 -0700 Lines: 45 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 NNTP-Posting-Host: 68.69.17.41 Message-ID: <44ad4c7c$1@newsgroups.borland.com> X-Trace: newsgroups.borland.com 1152207996 68.69.17.41 (6 Jul 2006 10:46:36 -0700) Path: arc1-ca.pugleaf.net!g2news2.google.com!news2.google.com!news.germany.com!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail