🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.cppbuilder.internet.socket
Article #2249

Re: Borland C++ 5 TServerSocket TimeOut

#2249
From: Remy Lebeau (TeamB)
Date: Thu, 06 Jul 2006 17:46
43 lines
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-mail
References: <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