🚀 go-pugleaf

That makes a ton of sense.  I will fix.

Eric


"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:44490c3a$1@newsgroups.borland.com...
>
> "Eric Patterson" <eric.patterson@bepco.com> wrote in message
> news:4448c637$1@newsgroups.borland.com...
>
>> That exception has gone away and since in this process of finding
> . my problems I removed clearing the errorcode integer on a Socket
>> OnError event, I came in this morning with an asynchronous socket
>> error 10053 which I already know is what the socket throws back
>> to me when it is full and busy.
>
> 10053 is an abnormal disconnect.  The socket forced itself to disconnect 
> due
> to an internal error.  That can happen for a number of reasons.  Being 
> "full
> and busy" is not likely to be the cause.  If the socket's internal buffer
> were simply full and couldn't accept more data yet, you would either get
> WSAENOBUFS as the ErrorCode in the OnError event, or you would not get the
> OnError event at all if WSAGetLastError() returns WSAEWOULDBLOCK, which 
> the
> VCL handles internally.
>
>> I would of expected this error soon after starting the app but it
>> didn't occur until 5 hours later.
>
> If you were filling up the socket's internal buffer after several hours,
> then that suggests to me that you are trying to send data faster than the
> socket can send it out, and the buffer slowly fills up over time. As I
> explained to you earler, if the socket reports WSAEWOULDBLOCK on a sent
> operation, then you *must* wait for the OnWrite event to be triggered 
> before
> you can send more data.  If your application needs to send data before 
> that
> happens, then you will just have to queue the data for later.
>
>> I will make the additions now that when I see a 10053 in the OnError
>> event to wait for a ClientWrite Event to occur before continuing on;
>> like we have discussed before.
>
> That is the wrong use of the OnWrite event.  10053 is a fatal error.  The
> connection is gone.  You have to reconect.
>
>
> Gambit
>
>