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

I am a little confused. Your first read is receiving 0 bytes? Well the
eventual read that does receive some bytes, i assume you do eventually
receive something, that will be your header. I think you are going to need
to post some code for this.


"semedao" <semedao@xxxxxxxxxxxxxxxx> wrote in message
news:OBny3GX2GHA.2176@xxxxxxxxxxxxxxxxxxxxxxx
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: Fundamentals question, is this how it works?
    ... processing packets after you are done with one. ... receving the buffer size each time. ... TCP is a stream-based protocol, which means that it ignores any attempt ... then the receiving side might get ...
    (microsoft.public.win32.programmer.networks)
  • Re: Datagram Socket Speed Problem
    ... I'd say that there's not a single thing wrong with the socket. ... When the buffer is full (because you're trying to send faster than the ... network bandwidth will allow), it tosses the packets. ... > The receiver program start receiving packets... ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Socket receiving too slowly
    ... How do you know the size of what you are receiving? ... > I'm using a socket connection to receive communication from a server. ... > to clean out the buffer, which due to the computer's business is holding ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Fundamentals question, is this how it works?
    ... You maintain a buffer for the last incomplete packet. ... receiving that many bytes i then break and wait for the next set of data ... With a tcp stream socket what happens when it is reading say 4000bytes ...
    (microsoft.public.win32.programmer.networks)
  • Re: Help regarding MSG_PEEK
    ... Is there any way to find the number of bytes filled in the socket ... For suppose if a UDP server application is receiving data on some ... How do I know the number of bytes filled in the buffer after it ... Doing this for each packet isn't going to be very efficient. ...
    (comp.unix.programmer)
Quantcast