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

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: TCPIP Default keep alive question
    ... since last December we have been getting ASOD abends in certain CICS ... Did you mean to alert us to the possibility that the *partner* TCP ... SO_KEEPALIVE socket option and do not override the interval using the ... TCP keepalive probes end TCP connections after a period of inactivity. ...
    (bit.listserv.ibm-main)
  • Re: TCPIP Default keep alive question
    ... Did you mean to alert us to the possibility that the *partner* TCP application ... SO_KEEPALIVE socket option and do not override the interval using the ... TCP keepalive probes end TCP connections after a period of inactivity. ... If the TCP_KEEPALIVE socket option is not used to specify the probe ...
    (bit.listserv.ibm-main)
  • Re: Socket stuck with puts over ADSL line
    ... gets stuck with the puts command within the filevent writeable ... Is the socket configured as -blocking 1? ... local buffer would fill rapidly, ... buffered portion across the WAN as its own TCP packet, ...
    (comp.lang.tcl)
  • Re: network programming: how does s.accept() work?
    ... The articles and books I've read all claim that the server ... port 5053 is a 'listening' port only. ... the server creates a new socket for communication between the client ... on the network, and in the RFCs which define the TCP protocol (UDP too, but ...
    (comp.lang.python)
  • Re: TCPIP Default keep alive question
    ... The default TCP keepalive interval for applications that enable the ... SO_KEEPALIVE socket option and do not override the interval using the ... TCP keepalive probes end TCP connections after a period of inactivity. ... If the TCP_KEEPALIVE socket option is not used to specify the probe ...
    (bit.listserv.ibm-main)