Re: Deaf CAsyncSocket on Windows Service.
I'm facing a similar problem with a class I derived from CAsyncSocket,
except it's not running in a service. Maybe what I've learned so far will
give a clue. Hopefully, someone can suggest a solution for both of us. All
my derived class does is send null terminated strings and on the receive
side, combine or split the data back into the null terminated strings that
were sent before making them available to the callback function above.
I use this class to communicate between two programs. Sometimes they are on
separate PCs but in this case they both run on the same. I've used this same
class in other projects without noticing this problem, although it just
might be so less frequent that I didn't notice. In the other projects, I
sent a command from one side and the sent the reply from the other. For this
project, there is a bunch of data being sent in one direction and fairly
asynchronously. But the strings are about 40 bytes and there are about 6 to
12 strings sent per second, so the amount of data is still small.
What I've discovered is that when the receiver stops hearing data, the data
IS still being sent. What's missing is the receiver socket did not get a
call to OnReceive() (or maybe did but didn't process it correctly). Sent
data is still building up in whatever internal buffer the CAsyncSocket has
for holding data until it is removed by the Receive() function. When the
receiver stops hearing, if I call OnReceive() manually by pressing a button
I added to the receiving program, the data starts flowing in again. But it
can hang again later.
My understanding of CAsyncSocket was that when I get the OnReceive callback,
I should call Receive() repeatedly until I get a WSAEWOULDBLOCK condition.
Then when more data is sent later, I would get another call to OnReceive().
Presumably if I don't empty the CAsyncSocket's internal buffer then when
more data comes in I would not get another OnReceive() call. So my derived
class's OnReceive() call does Receive() data until the WSAEWOULDBLOCK
With all the uninteresting stuff removed, here's my function below. I have
breakpoints on the first and third break; statements and they are never hit,
so I know that I am always getting the WSAEWOULDBLOCK condition and leaving
the loop through the second break; statement. I just noticed that I'm not
checking the nErrorCode input, so I will test that when I get back to work
later this morning. Currently my pBuffer is on the small side but I've
tested with smaller and larger and the problem is not solved. Basically it's
small now so I could test the ability of the function to parse correctly
through the data and recombine it into the strings as they were sent.
Can anyone suggest why this isn't working and a solution? If I were to
receive a nonzero value in nErrorCode, how should I handle it.
void CMySocket::OnReceive(int nErrorCode)
if((dwBytes = CAsyncSocket::Receive(&pBuffer, sizeof(pBuffer) - 1)) ==
SOCKET_ERROR) // an error occurred
if ((m_lastError = GetLastError()) == WSAEWOULDBLOCK)
m_lastError = 0;
break; // an error occurred
else if(dwBytes == 0) // the socket has closed
else // data is available
// process pBuffer here and call callback for each null terminated
"David Ching" <email@example.com> wrote in message
"Ricardo Vazquez" <firstname.lastname@example.org> wrote in message
This is my problem:
On an application of mine, which is a Windows Service, developed with
VC++ 6.0, I use an UDP CAsyncSocket derived class.
On most installations (nearly one hundred different PCs) it runs
But there are two installations (one has Win2000, the other Win2003)
where we find this problem:
After several hours running (20 - 30 hours), it suddenly becomes deaf.
Can you attach to the service process and debug it? If so, it becomes
easy to see what your CAsyncSocket is doing.
I've heard that CAsyncSocket may have problems when used within a Windows
Can any of you confirm this information?
Is it true that CAsyncSocket should not be used in Windows Services?
Is there a way to patch this supposed bug?
Should I turn to Platform SDK plain "SOCKET"?
I don't know about CAsyncSocket and services. But if you want an
alternative to SOCKET, try Ultimate TCP/IP from CodeProject (open source).