Re: Deaf CAsyncSocket on Windows Service.

I never once said the word 'packet'.

There are a number of bytes of data to be read and I can't find out how many
bytes that is except to read them out. To read them out I need a buffer to
put them into and I don't know how big that buffer should be if I don't know
the number of bytes waiting to be received. So there is a possibility that I
might not read out all the bytes and that some bytes will remain. So it's a
valid question to ask if I will get another OnReceive() call, as earlier I
was under the (wrong) impression that I had to read out all the bytes until
I got a 'would block' condition.

Perhaps the guy that said 'packets' should have said 'bytes of data'
instead, but I understood what he meant. Data has to be sent before it can
be received and I'm sure he meant that data from two separate sends are
received at two separate times and this might have some affect if Receive()
has not been called.

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.

And Steve, I'm not sure where we both got the idea that all the data needs
to be read out in any OnReceive() call, but this latest test seems to say
that that is not correct.

Bill


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:iq8cn45e7nl3r8q3qq72448233vteqeumo@xxxxxxxxxx
See below...
On Tue, 20 Jan 2009 10:21:06 +0800, "Bill Brehm" <<don't want spam>>
wrote:

Scott,

I think there is no way to find out before the Receive() call how much
data
is waiting to be received, right? So I have to select an arbitrary buffer
size to read the data into. What happens if the amount of data I read out
is
not all the data that's in their waiting to be read? Will I get a second
OnReceive() call for the data that came in already that I failed to read
out?
*****
Yes. You get an OnReceive notification if there is input data to be read.
Why you have
concluded this has something to do with "packets" escapes me. It doesn't,
and never did.
Packets are some uninteresting low-level implementation detail that is
invisible to you.
****

My problem (in another branch of this thread) is that I seem to lose the
OnReceive() call rather than getting extra. I don't know if I am getting
extra calls (I will check this when i'm back at work soon) but if I am,
they
would just break out with the WSAEWOULDBLOCK condition and cause no harm
in
my case.

I will test with a single call to Receive() inside of OnReceive() and see
if
the problem goes away. But I would like to understand why the error is
occurring.
*****
I'm not sure why the error is occurring, but the explanations you are
suggesting are not
correct. There might be other reasons, but "packets arriving" have
nothing to do with the
problem.
joe
******

Thanks,

Bill


"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:%23838bDpeJHA.3708@xxxxxxxxxxxxxxxxxxxxxxx

"Stephen Myers" <StephenMyers@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:5E3F541A-A5B5-4B47-8651-BA120F86CD9E@xxxxxxxxxxxxxxxx
Is there any posibility that the data is being received but not
triggering
OnReceive()?

This can happen when two (or more) packets are received without a
Receive()
call. If you are doing the Receive() in as part of the OnReceive()
handling,
make sure there is no data left prior to exiting OnReceive().

Steve

On the contrary. Every call to Receive enables the message that will
produce the next call to OnReceive. It is therefore recommended that
Receive should be called only once per OnReceive notification. It is
not
true that one must continue to call Receive until it would block.
(Reference: the MSDN page for WSAAsyncSelect - "an application need not
read all available data in response to an FD_READ message - a single
recv
in response to each FD_READ message is appropriate.")

And, if Receive is called more than once in OnReceive there is a
possibility that another OnReceive notification message (FD_READ) is
left
in the queue, and when it is processed later there will be no data.

Suggestion: Call Receive one time only per OnReceive, and make sure the
processing of received data does not permit the message pump to execute
until after you have returned from OnReceive. Both of these steps are
necessary to avoid the possibility of OnReceive and Receive getting out
of
sync.

--
Scott McPhillips [VC++ MVP]

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm


.

Relevant Pages

  • Re: Deaf CAsyncSocket on Windows Service.
    ... To read them out I need a buffer to ... Short packets at the sender are coalesced into longer packets. ... THe receiver says "I have this much buffer space" and the sender is free to send ... You get an OnReceive notification if there is input data to be read. ...
    (microsoft.public.vc.mfc)
  • Re: Deaf CAsyncSocket on Windows Service.
    ... not all the data that's in their waiting to be read? ... You get an OnReceive notification if there is input data to be read. ... Packets are some uninteresting low-level implementation detail that is invisible to you. ... read all available data in response to an FD_READ message - a single recv ...
    (microsoft.public.vc.mfc)
  • Re: Losing UDP packets with MFC Sockets
    ... Receive you will pick up both packets in one buffer. ... >> Your receiving process does a Receive with a buffer of 100 bytes the ...
    (microsoft.public.vc.mfc)
  • Re: In-tree version of new FireWire drivers available
    ... Just to recap, the dual buffer receive mode, as described in section ... quadlet aligned amount of header data can be appended into one buffer ... *either* the header buffer or the payload buffer fills up. ... enough to hold headers for all the packets it takes to fill up the ...
    (Linux-Kernel)
  • Re: Cisco 7204VXR Interface ignored packet
    ... Input queue drops (ignored packets) are usually due to buffers not being ... The buffer defaults are good 98% of the ... 256 max cache size, 256 in cache ... 22496866 hits in cache, 0 misses in cache ...
    (comp.dcom.sys.cisco)
Loading