🚀 go-pugleaf

"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