Re: BeginReceive return zero length buffer when run ,and work correctly when use step by step debug mode

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hi Daniel,
this is exaclty what I already did!
but , when I want to read the first 5 btes (my header , 1 more byte for
"command" ) , I receive the zero length !
it's happen in the first read , before I start the loop of
header->packet->header->packet...

"Daniel" <DanielV@xxxxxxxxxxxxxxxx> wrote in message
news:OkhCwCT2GHA.2036@xxxxxxxxxxxxxxxxxxxxxxx
Hey Sem

Since i have implemented what you are doing successfully and did in fact
get it right that you are 'losing' bytes i will continue to try and help.

the reason i believe you are losing data is the exact reason that i was
when i first attempted this.

Ok imagine this, you send a total of 800 bytes, and your buffer is 500
bytes in size (500 for arguments sake to keep numbers easy)

Your async socket listens and receives 500 bytes (your total buffer size
with still 300 to come), you read the full buffer and then finish. Now the
next 300 comes through and so you receive 300 bytes.

So your second receive is a 500 byte buffer with only 300 byes of data in
it.

So when you hit the 300th byte of that 500 check your code and see if at
this point you stop reading, as after all you have your data, and break.
If so you just lost 200 bytes. Sure that 200 bytes may be empty but it
might not. If another send was done at the other end it may have been
joined on the end. and your break just ignored it.

So this is what you must remember:

1) Send 4 bytes containing the ength of the data being sent
2) receiveing end, read first 4 bytes and store size of data to come
3) read that many bytes and use the end of those bytes not as a point to
break and say end of transmission but end of that object being received
and now...
4) ....now the next 4 bytes check for size again and so on ans so on

So to clarfiy further. Imagine sending an object of 1024 bytes in size. We
would do this

a) create 4 bytes containing the length of the data being sent, the number
1024
b) send the 4 bytes
c) send the data
d) receive and
1)first receive check first 4 bytes to get size expected
2) read that many bytes
3) on reading that many bytes check next 4 bytes received for expected
size of next data comin thorugh
4) if expected size now is 0 then no more to come, go back to active
waiting state
5) if not 0 then read as usual and so on


Does that make sense?





"semedao" <semedao@xxxxxxxxxxxxxxxx> wrote in message
news:OCyEJLS2GHA.4116@xxxxxxxxxxxxxxxxxxxxxxx
Hi , I take back my words about missing data... :))
ok ok , the data is missing , but , help me understand
why ??
firsy - yes , I am using TCP
now , If I made loop around the "beginRecv until it will return the
expected buffer length , the app is in infinite loop in case when the
return of endrecv is zero.
so , how can I handle it ?

"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:12gmb2nbgkm1u2a@xxxxxxxxxxxxxxxxxxxxx
"Daniel" <DanielV@xxxxxxxxxxxxxxxx> wrote in message
news:%23BR8lqQ2GHA.3576@xxxxxxxxxxxxxxxxxxxxxxx
I didn't read all of Peters reply but he did mention the delay fixing
it. Also you said 'no' to my comment that your 'losing data.

Well if when you debug you receive 5 bytes and when you don't debug you
don't recive 5 bytes....haven't you lost data?

Not necessarily. All we know is that he doesn't receive the data when
he expected to. Since he has no loop around his receive attempt, he
definitely will fail to read the data if it's not read the first time
through. But the data remains on the socket, until such time as it IS
read or the socket is closed. It's entirely possible that his code does
eventually read the data, preventing it from being lost.

I'd say if he says he doesn't lose data, we should take his word for it,
at least for the moment. :)

In addition...

the fatc you reminded me you are using async sockets makes me think
your new to it.

I have written commerical software using async sockets in .net 2.0 and
when i was learning i had the exact same problem,.

What i didn't know at the time was a few key things:

1) data will never go out of order
2) you will never lose bytes
3) you may receive all your data in one stream call

So say you sent 10 bytes, then 5 bytes then 5 more bytes

Your endreceive may return : 20bytes.......it may return 10, then 5
then 5...(as in when there is a delay due to debugging), or it may
return 15 then 5.

All true. However, the thing that many programmers miss (and which you
didn't mention) is that you may not even receive 10 bytes or 5 bytes or
any given number of bytes for any given call to receive.

In your example, the sender sends 20 bytes. The receiver may in fact
wind up receiving 1 byte at a time, 20 times, and the code must be
prepared to deal with this. In reality, the extreme cases almost never
happen (eg getting just one byte at a time) but the API specification
doesn't guarantee anything better than that, and if your code isn't
handling that degenerate case, it likely also doesn't handle the more
likely cases as well.

With a stream-oriented socket (eg TCP), there are no message boundaries.
The way the data is grouped during the send has nothing to do with the
way the data is grouped during the receive.

Now, as it happens, we don't really know whether the original poster is
using a stream-oriented socket. I didn't see anything in his post or
code that implies TCP (or similar protocol). If he's using UDP, all of
the above isn't relevant and there's a whole different set of
considerations (ie, one receive always returns exactly what one send
sent, but you may receive the same datagram more than once, not at all,
or out of order from the other datagrams).

The real issue here appears to be what "blocking" and "non-blocking"
mean with respect to the .NET implementation of sockets. I suspect that
even though the documentation says otherwise, the EndReceive method only
blocks until the receive is completed when a blocking socket is used
(and of course, as you point out, for a TCP socket "complete" does not
necessary mean "the buffer has been filled"...it just means *some* data
has been received).

Pete







.

Relevant Pages

  • Re: BeginReceive return zero length buffer when run ,and work correctly when use step by step debug
    ... it right that you are 'losing' bytes i will continue to try and help. ... Ok imagine this, you send a total of 800 bytes, and your buffer is 500 bytes ... receiveing end, read first 4 bytes and store size of data to come ... But the data remains on the socket, until such time as it IS ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Non blocking socket query.
    ... > containing output buffer, status info etc). ... > write as much data as possible to the socket. ... better to have an inner loop getting messages until there ... > want to prevent remote applications sending data to me. ...
    (comp.unix.programmer)
  • Re: Socket Server buffer size
    ... Recive Len bytes in your buffer until you get Len bytes in your loop. ... | My application uses an asynchronous socket server. ... | I'd like to avoid repeatedly reading socket to get full data packet since ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Communication speed between blocking call and non blocking cal
    ... You could use event based notification, ... When you use nonblocking I/O, the system may have to perform extra buffering ... data buffer until you say that you are done with it. ... I checked default socket buffer ...
    (microsoft.public.win32.programmer.networks)
  • Re: strange select() behavior
    ... sharing descriptors, might fill that interface buffer. ... What do you do when a blocking socket operation returns ENOBUFS? ... because it's a semantic change. ...
    (comp.unix.programmer)