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
condition.

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.

Thanks,

Bill

void CMySocket::OnReceive(int nErrorCode)
{
  BYTE pBuffer[25];
  int dwBytes;

  while(true)
  {
    if((dwBytes = CAsyncSocket::Receive(&pBuffer, sizeof(pBuffer) - 1)) ==
SOCKET_ERROR) // an error occurred
    {
      if ((m_lastError = GetLastError()) == WSAEWOULDBLOCK)
      {
        m_lastError = 0;
      }
      else
      {
        break; // an error occurred
      }
      break;
    }
    else if(dwBytes == 0) // the socket has closed
    {
      break;
    }
    else // data is available
    {
       // process pBuffer here and call callback for each null terminated
string received
    }
  }
}

"David Ching" <dc@remove-this.dcsoft.com> wrote in message
news:0B404BDA-A6BD-4742-BA98-7C0CBA678028@microsoft.com...