Re: Deaf CAsyncSocket on Windows Service.

From:

"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp>

Newsgroups:

microsoft.public.vc.mfc

Date:

Tue, 20 Jan 2009 22:11:36 -0500

Message-ID:

<#WAEAY3eJHA.5956@TK2MSFTNGP06.phx.gbl>

"Bill >" <<don't want more spam> wrote in message
news:u7VDL$2eJHA.5408@TK2MSFTNGP03.phx.gbl...

I did further testing and changed to only one Receive() per OnReceive(),
instead of a loop. The problem has not occurred since. I switched back and
it occurred quickly. So it seems likely that this was the cause. What
confuses me is that my old way worked on several projects and even on this
project worked many many many times before failing. So reading all the
data until 'would block' works most of the time but not all the time.
Since the data sends, and therefore the data receives are asynchronous in
this project, I must assume the failure happens when something like an
unlucky timing coincidence between Send(), OnReceive(), Receive() and data
being received occurs. But since this is hard to prove, I would still like
confirmation from someone that knows for sure. I'd like to be 100% sure
rather than 95%. Thanks.

You can be confident that the underlying winsock design is immune to the
asynchronous timing coincidences that can occur. It is the foundation of
all Windows network communication.

The weak point that you seem to have encountered (and that I have definitely
encountered) is that the OnReceive notification is a message in the Windows
message queue. If OnReceive somehow lets a message loop run (such as by
displaying MessageBox) that message loop could discard a waiting OnReceive
notification. And if you lose one you lose them all, because no more will
be generated until Receive is called. So the failure mode depends not only
on asynchronous timing, but also on OnReceive running a message loop.

--
Scott McPhillips [VC++ MVP]