473,903 Members | 3,386 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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

Hi , I am using asyc sockets p2p connection between 2 clients.
when I debug step by step the both sides , i'ts work ok.
when I run it , in somepoint (same location in the code)
when I want to receive 5 bytes buffer , I call the BeginReceive and then
wait on AsyncWaitHandle .WaitOne()
but it is signald imidiatly , and the next call to EndReceive return zero
bytes length , also the buffer is empty.
here is the code:
public static byte[] Receive(Socket OpenSocket, int length)

{

byte[] buffer = new byte[length];

int totalreceive = 0;

int _lastReceive = 0;

if (OpenSocket.Blo cking)

totalreceive = OpenSocket.Rece ive(buffer);

else

{

IAsyncResult ar;

do

{

//in this point the OpenSocket.Avai lable == 0 !

ar = OpenSocket.Begi nReceive(buffer , 0, length, SocketFlags.Non e, null,
null);

ar.AsyncWaitHan dle.WaitOne(); // something "signald it before data received?

_lastReceive = OpenSocket.EndR eceive(ar);

if (_lastReceive == 0) // happen when run the code , doeas not happen if
step by step slowly!

{

buffer = null;

throw new Exception("No data receive");

}

totalreceive += _lastReceive;

} while (totalreceive < length);

}

return buffer;

}

what is my problem ? I don't want to use sync calls because the rest of the
session is async also , so I only want to makethe async - sinc like forthis
part ofthe code , also , when in the debug mode I change the
OpenSocket.Bloc king to True - cause it to call sync receive instead of
beginrecv , also return with zero length buffer

any ideas ?
Sep 15 '06 #1
22 4061
Bit confused by what you are saying is the problem but can you calrify.

If you send an object to the other client, it is not always getting there.
But if you debug, it does? Is the problem that you are 'losing' bytes?
"semedao" <se*****@commun ity.nospamwrote in message
news:ei******** ******@TK2MSFTN GP02.phx.gbl...
Hi , I am using asyc sockets p2p connection between 2 clients.
when I debug step by step the both sides , i'ts work ok.
when I run it , in somepoint (same location in the code)
when I want to receive 5 bytes buffer , I call the BeginReceive and then
wait on AsyncWaitHandle .WaitOne()
but it is signald imidiatly , and the next call to EndReceive return zero
bytes length , also the buffer is empty.
here is the code:
public static byte[] Receive(Socket OpenSocket, int length)

{

byte[] buffer = new byte[length];

int totalreceive = 0;

int _lastReceive = 0;

if (OpenSocket.Blo cking)

totalreceive = OpenSocket.Rece ive(buffer);

else

{

IAsyncResult ar;

do

{

//in this point the OpenSocket.Avai lable == 0 !

ar = OpenSocket.Begi nReceive(buffer , 0, length, SocketFlags.Non e, null,
null);

ar.AsyncWaitHan dle.WaitOne(); // something "signald it before data
received?

_lastReceive = OpenSocket.EndR eceive(ar);

if (_lastReceive == 0) // happen when run the code , doeas not happen if
step by step slowly!

{

buffer = null;

throw new Exception("No data receive");

}

totalreceive += _lastReceive;

} while (totalreceive < length);

}

return buffer;

}

what is my problem ? I don't want to use sync calls because the rest of
the session is async also , so I only want to makethe async - sinc like
forthis part ofthe code , also , when in the debug mode I change the
OpenSocket.Bloc king to True - cause it to call sync receive instead of
beginrecv , also return with zero length buffer

any ideas ?


Sep 15 '06 #2
No,
I have some send recv conversation between 2 clients
the mode is async sockets.
when I come to some location in the code that I want to recv 5 bytes , the
recv return before the bytes received , the length of the EndRecv() is 0
(zero) ,
I use the async result of the BeginReceive() WaitHandle.Wait One() to block
on this thread until the bytes come , but , it does not block and return as
I described above.
When I debug this process of the both clients STEP by STEP , it's work
correctly and return those 5 bytes !
so , I can't find whay it's happen !
"Daniel" <Da*****@vestry online.comwrote in message
news:ub******** ******@TK2MSFTN GP05.phx.gbl...
Bit confused by what you are saying is the problem but can you calrify.

If you send an object to the other client, it is not always getting there.
But if you debug, it does? Is the problem that you are 'losing' bytes?
"semedao" <se*****@commun ity.nospamwrote in message
news:ei******** ******@TK2MSFTN GP02.phx.gbl...
>Hi , I am using asyc sockets p2p connection between 2 clients.
when I debug step by step the both sides , i'ts work ok.
when I run it , in somepoint (same location in the code)
when I want to receive 5 bytes buffer , I call the BeginReceive and then
wait on AsyncWaitHandle .WaitOne()
but it is signald imidiatly , and the next call to EndReceive return zero
bytes length , also the buffer is empty.
here is the code:
public static byte[] Receive(Socket OpenSocket, int length)

{

byte[] buffer = new byte[length];

int totalreceive = 0;

int _lastReceive = 0;

if (OpenSocket.Blo cking)

totalreceive = OpenSocket.Rece ive(buffer);

else

{

IAsyncResult ar;

do

{

//in this point the OpenSocket.Avai lable == 0 !

ar = OpenSocket.Begi nReceive(buffer , 0, length, SocketFlags.Non e, null,
null);

ar.AsyncWaitHa ndle.WaitOne(); // something "signald it before data
received?

_lastReceive = OpenSocket.EndR eceive(ar);

if (_lastReceive == 0) // happen when run the code , doeas not happen if
step by step slowly!

{

buffer = null;

throw new Exception("No data receive");

}

totalreceive += _lastReceive;

} while (totalreceive < length);

}

return buffer;

}

what is my problem ? I don't want to use sync calls because the rest of
the session is async also , so I only want to makethe async - sinc like
forthis part ofthe code , also , when in the debug mode I change the
OpenSocket.Blo cking to True - cause it to call sync receive instead of
beginrecv , also return with zero length buffer

any ideas ?



Sep 15 '06 #3
"semedao" <se*****@commun ity.nospamwrote in message
news:en******** ******@TK2MSFTN GP06.phx.gbl...
[...]
I use the async result of the BeginReceive() WaitHandle.Wait One() to block
on this thread until the bytes come , but , it does not block and return
as I described above.
When I debug this process of the both clients STEP by STEP , it's work
correctly and return those 5 bytes !
so , I can't find whay it's happen !
Disclaimer: while I've done plenty of Winsock programming, I haven't used
sockets in .NET yet. Still, I have what I think is a good guess as to
what's going on...

I believe that you misunderstand what the behavior of Begin/EndReceive is
(possibly because the documentation is misleading or incorrect). In
particular, assuming it works like the other async stuff in .NET, it does
NOT actually wait for data to be present on a non-blocking socket when you
wait on the AsyncResult or call EndReceive). All it does is cause the
particular call to Receive to happen on a different thread so that your own
thread can continue working. But in the other thread, it's like calling
Receive directly. There's no additional processing to check for data being
available.

So, in this case you've got a non-blocking socket, and the receive operation
completes essentially immediately since there's no data, and when you check
the results there is no data.

By stepping through (or probably any other delay), you allow time for the
data to get into the socket's receive buffer and become available to receive
in your thread.

In other words, using BeginReceive instead of Receive only makes sense if
you have a blocking socket. If you have a non-blocking socket, you need to
continue to use the normal i/o notification mechanism that you've chosen for
use with that socket.

IMHO, it's a little odd that EndReceive returns a value. If it were
completely analogous to the normal Winsock behavior, it'd throw (or return,
in the overload that returns an exception as a parameter) an exception when
no data is present (whatever the equivalent to WSAEWOULDBLOCK is...that is,
a SocketException where ErrorCode is set to WSAEWOULDBLOCK) .

I realize that all of the above is in direct contradiction to the
documentation (in particular, the documentation for EndReceive reads in part
"The EndReceive method will block until data is available"). But given the
behavior you're seeing, and given how Winsock (the underlying Win32 API)
actually works, I think it's more likely that the documentation is wrong.
Making EndReceive blocking on a non-blocking socket would be non-trivial
(though not terribly difficult) and doing so would significantly reduce the
uniformity of the behavior of "End..." functions.

All that said, a quick look through the .NET Sockets documentation didn't
turn up anything that I recognized as a normal use of a non-blocking socket
other than Select. That is, you can get and set the Blocking property, but
I don't see any means other than calling Sockets.Select to find out when
it's reasonable to call Receive or Send on a socket. So to address the
above, the only solution I can see is to use the Select method to wait until
the socket becomes readable (and of course, depending on the .NET
implementation of Select, you may have to loop until you get the data you
want (or any data at all for that matter...in Winsock, calling select() does
not guarantee that when you get to the call to recv() you will actually get
any data back, even though most often that is the case).

If you are using the Blocking property, I assume that you actually know
about Select and any other mechanism that is similar, so hopefully there's
enough information here for you to get things working.

Pete
Sep 15 '06 #4
Hello again,

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?

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.......i t may return 10, then 5 then
5...(as in when there is a delay due to debugging), or it may return 15 then
5.

When i had the sam problem as you it was because i was doing the end reieve,
reading the received bytes, then breaking out of my loop and waiting for
more data on the socket. That point where i broke i lost remining data. So
only when the correct amount came through in one call did i get it all.
Sound slike your issue.

So make sure you read very byte that comes in. If your buffer is 1024 bytes
and you receive 1024 bytes, read them all. And be sure to send the size
expected along too. So you know how much to read of each object sent. And
remmber you need to handle overlap.

For example if your buffer is 1024 bytes in size and you have an object of
1023 bytes and you alway send the first 4 bytes before any send as the size
of data to come, then the 1024th byte, and then the 1st, 2nd and 3rd bytes
of the next receive will be that 4byts size of the next data block coming
in.

If what i say above confuses then re-read sockets, your understanding is
flawes. As i say Peter may have already explained this to you.

"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:12******** *****@corp.supe rnews.com...
"semedao" <se*****@commun ity.nospamwrote in message
news:en******** ******@TK2MSFTN GP06.phx.gbl...
>[...]
I use the async result of the BeginReceive() WaitHandle.Wait One() to
block on this thread until the bytes come , but , it does not block and
return as I described above.
When I debug this process of the both clients STEP by STEP , it's work
correctly and return those 5 bytes !
so , I can't find whay it's happen !

Disclaimer: while I've done plenty of Winsock programming, I haven't used
sockets in .NET yet. Still, I have what I think is a good guess as to
what's going on...

I believe that you misunderstand what the behavior of Begin/EndReceive is
(possibly because the documentation is misleading or incorrect). In
particular, assuming it works like the other async stuff in .NET, it does
NOT actually wait for data to be present on a non-blocking socket when you
wait on the AsyncResult or call EndReceive). All it does is cause the
particular call to Receive to happen on a different thread so that your
own thread can continue working. But in the other thread, it's like
calling Receive directly. There's no additional processing to check for
data being available.

So, in this case you've got a non-blocking socket, and the receive
operation completes essentially immediately since there's no data, and
when you check the results there is no data.

By stepping through (or probably any other delay), you allow time for the
data to get into the socket's receive buffer and become available to
receive in your thread.

In other words, using BeginReceive instead of Receive only makes sense if
you have a blocking socket. If you have a non-blocking socket, you need
to continue to use the normal i/o notification mechanism that you've
chosen for use with that socket.

IMHO, it's a little odd that EndReceive returns a value. If it were
completely analogous to the normal Winsock behavior, it'd throw (or
return, in the overload that returns an exception as a parameter) an
exception when no data is present (whatever the equivalent to
WSAEWOULDBLOCK is...that is, a SocketException where ErrorCode is set to
WSAEWOULDBLOCK) .

I realize that all of the above is in direct contradiction to the
documentation (in particular, the documentation for EndReceive reads in
part "The EndReceive method will block until data is available"). But
given the behavior you're seeing, and given how Winsock (the underlying
Win32 API) actually works, I think it's more likely that the documentation
is wrong. Making EndReceive blocking on a non-blocking socket would be
non-trivial (though not terribly difficult) and doing so would
significantly reduce the uniformity of the behavior of "End..." functions.

All that said, a quick look through the .NET Sockets documentation didn't
turn up anything that I recognized as a normal use of a non-blocking
socket other than Select. That is, you can get and set the Blocking
property, but I don't see any means other than calling Sockets.Select to
find out when it's reasonable to call Receive or Send on a socket. So to
address the above, the only solution I can see is to use the Select method
to wait until the socket becomes readable (and of course, depending on the
.NET implementation of Select, you may have to loop until you get the data
you want (or any data at all for that matter...in Winsock, calling
select() does not guarantee that when you get to the call to recv() you
will actually get any data back, even though most often that is the case).

If you are using the Blocking property, I assume that you actually know
about Select and any other mechanism that is similar, so hopefully there's
enough information here for you to get things working.

Pete

Sep 15 '06 #5
"Daniel" <Da*****@vestry online.comwrote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..
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.......i t 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
Sep 15 '06 #6
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" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:12******** *****@corp.supe rnews.com...
"Daniel" <Da*****@vestry online.comwrote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..
>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.......i t 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

Sep 15 '06 #7
"semedao" <se*****@commun ity.nospamwrote in message
news:OC******** ******@TK2MSFTN GP02.phx.gbl...
Hi , I take back my words about missing data... :))
ok ok , the data is missing , but , help me understand
why ??
At what point is it missing? Do you ever try to read from the socket again
after getting a 0 return value from EndReceive and throwing an exception? I
think that's an important clarification.
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 ?
oopsie on my part. I didn't notice you had the whole non-blocking scenario
wrapped in a do/while loop. I think your loop is fine (except that it
didn't include the blocking case), and should in fact keep control within
the loop until you've read sufficient data (as long as you don't throw an
exception, so the first step is to take that out as a response to receiving
a 0 return value).

Secondly, I would forget (at least for the moment) using Begin/EndReceive.
I think it's an unnecessary distraction, especially since you want your code
to block anyway. Use a regular Receive. With a non-blocking socket, you'll
want to also call Socket.Select to block your thread until data is available
on the socket. Since I haven't used .NET sockets, I don't really know
whether you're using the Begin/EndReceive functions correctly, but they seem
to me to be unneeded here, since you don't intend for your thread to
continue doing some other work after calling BeginReceive.

Third, I finally noticed a bug in your call to Receive, in which you fail to
update the buffer offset. I don't think this would cause the issue you're
asking about, but it's a serious problem.
Here's how I'd try to write it (note of course that not having used sockets
in .NET, I can't guarantee this is perfectly correct :) ):

public static byte[] Receive(Socket openSocket, int length)
{
byte[] buffer = new byte[length];
int totalreceive = 0;

do
{
int lastreceive;

/*
* For non-blocking sockets, the Socket.Select method will block
* the thread until there is actually data to be read from the
socket.
*
* If you want to get really picky, check to make sure your socket
* is still in the socklistRead list before trying to read from it.
* Since it's the only one that was in there to begin with, it still
* should be and even if it's not the worst that can happen is we
* loop back around and try again.
*/
if (!openSocket.Bl ocking)
{
ArrayList socklistRead = new ArrayList();

socklistRead.Ad d(openSocket);
Socket.Select(s ocklistRead, null, null, -1);
}

/* Be prepared for an exception */
try
{
/*
* For blocking socket, this will block the thread until
* data is available. For a non-blocking socket, we hope
* that the data is still there after returning from
* Socket.Select, but it's no big deal if it's not (we'll
* get a WSAEWOULDBLOCK error and go back to try again).
*/
lastreceive = openSocket.Rece ive(buffer, totalreceive, length,
SocketFlags.Non e);

/*
* Sockets will return zero if the socket is
* closed and we've already read all the data on the socket
*/
if (lastreceive == 0)
{
throw new Exception("Sock et was closed");
}
}
catch (SocketExceptio n exc)
{
/*
* WSAEWOULDBLOCK is a non-fatal error...we just need to
* go back and try again.
*/
if (exc.ErrorCode != WSAEWOULDBLOCK)
{
throw;
}
lastreceive = 0;
}
catch
{
throw;
}

/*
* At this point, we've received valid data, and it's been
* put into the buffer. Update our byte counter to reflect
* that.
*/
totalreceive += lastreceive;
length -= lastreceive;
} while (length 0);
}

By the way, there is a Socket.Receive overload that takes an "out ErrorCode"
parameter. The docs claim that even this method returns an exception in the
case of a Winsock error, but I suspect that in reality the function returns
SOCKET_ERROR (-1) and sets the output parameter (this would be consistent
with how Winsock itself works). I didn't bother to try it to see, since
other exceptions can still happen anyway, but if it's true that you can
detect WSAEWOULDBLOCK that way instead, it might be nicer to use that
instead of having to use a try/catch block within the loop. Instead of:

try
{...}
catch (SocketExceptio n...)
{...}
catch
{...}

You'd have something like this:

lastreceive = openSocket.Rece ive(..., err);
if (lastreceive == SOCKET_ERROR)
{
if (err != WSAEWOULDBLOCK)
{
throw new SocketException (err);
}

lastreceive = 0;
}
else if (lastreceive == 0)
{
throw new Exception("Sock et was closed");
}

Note the extensive use of ellipsis' to denote code I didn't want to bother
typing out. :)

Anyway, I hope this helps. I'm making the (possibly incorrect) assumption
that the .NET version of sockets doesn't stray too far from the underlying
functionality. I essentially translated what I do know to be correct for
Winsock generally into the means and methods available in .NET. With some
luck, it'll be exactly what you need. :)

Pete
Sep 16 '06 #8
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" <se*****@commun ity.nospamwrote in message
news:OC******** ******@TK2MSFTN GP02.phx.gbl...
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" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:12******** *****@corp.supe rnews.com...
>"Daniel" <Da*****@vestry online.comwrote in message
news:%2******* *********@TK2MS FTNGP03.phx.gbl ...
>>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.......i t 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
consideratio ns (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


Sep 16 '06 #9
Not sure what is wrong with your code, but here is some that should work for
you.

public delegate void GetBytesDelegat e(byte[] buf, Exception ex);
public static void GetBytes(Socket s, int length, GetBytesDelegat e
callback)
{
if (length < 1)
throw new ArgumentOutOfRa ngeException("l ength");

byte[] buffer = new byte[length];
int bytesRead = 0;

AsyncCallback cb = null;
cb = delegate(IAsync Result ar)
{
try
{
int read = s.EndReceive(ar );
if (read == 0)
{
callback(null, null); // Peer closed send.
return;
}

bytesRead += read;

if (bytesRead == length)
callback(buffer , null); // Done.
else // Else, need more data.
s.BeginReceive( buffer, bytesRead, length -
bytesRead, SocketFlags.Non e, cb, null);
}
catch (Exception ex)
{
callback(buffer , ex);
}
};

s.BeginReceive( buffer, bytesRead, length - bytesRead,
SocketFlags.Non e, cb, null);
}

--
William Stacey [MVP]

"semedao" <se*****@commun ity.nospamwrote in message
news:ei******** ******@TK2MSFTN GP02.phx.gbl...
| Hi , I am using asyc sockets p2p connection between 2 clients.
| when I debug step by step the both sides , i'ts work ok.
| when I run it , in somepoint (same location in the code)
| when I want to receive 5 bytes buffer , I call the BeginReceive and then
| wait on AsyncWaitHandle .WaitOne()
| but it is signald imidiatly , and the next call to EndReceive return zero
| bytes length , also the buffer is empty.
| here is the code:
| public static byte[] Receive(Socket OpenSocket, int length)
|
| {
|
| byte[] buffer = new byte[length];
|
| int totalreceive = 0;
|
| int _lastReceive = 0;
|
| if (OpenSocket.Blo cking)
|
| totalreceive = OpenSocket.Rece ive(buffer);
|
| else
|
| {
|
| IAsyncResult ar;
|
| do
|
| {
|
| //in this point the OpenSocket.Avai lable == 0 !
|
| ar = OpenSocket.Begi nReceive(buffer , 0, length, SocketFlags.Non e, null,
| null);
|
| ar.AsyncWaitHan dle.WaitOne(); // something "signald it before data
received?
|
| _lastReceive = OpenSocket.EndR eceive(ar);
|
| if (_lastReceive == 0) // happen when run the code , doeas not happen if
| step by step slowly!
|
| {
|
| buffer = null;
|
| throw new Exception("No data receive");
|
| }
|
| totalreceive += _lastReceive;
|
| } while (totalreceive < length);
|
| }
|
| return buffer;
|
| }
|
| what is my problem ? I don't want to use sync calls because the rest of
the
| session is async also , so I only want to makethe async - sinc like
forthis
| part ofthe code , also , when in the debug mode I change the
| OpenSocket.Bloc king to True - cause it to call sync receive instead of
| beginrecv , also return with zero length buffer
|
|
|
| any ideas ?
|
|
Sep 16 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

18
2963
by: Xiangliang Meng | last post by:
Hi. void setValue(int n) { int size = getValueLength(); int buffer_p; if (buffer_p) { ....
0
4244
by: ?lafur Helgi R?gnvaldsson | last post by:
I'm building a server application which accepts socket connections and I ran into some problems. The socket is asynchronous and therefore uses the BeginXXX and EndXXX methods in the Socket class to receive data. I also use a ManualResetEvent to signal the main thread when data arrives. Here is the code I'm running: using System;
1
13751
by: Mark Smith | last post by:
Dear Readers, I am in the process of implementing a non-blocking ASYNC TCP client using the .Net socket class. I am a little confused by the MSDN example. I have pasted the code here. private static void ReceiveCallback( IAsyncResult ar ) { try { // Retrieve the state object and the client socket // from the asynchronous state object.
18
2285
by: Seeker | last post by:
I essentially copied this program from K&R: #include <stdio.h> #include <stdlib.h> int main() { int c;
2
2279
by: Marcel Brekelmans | last post by:
Hi, I use a socket to receive data from a certain process. I use the asynchronous operations BeginReceive() and EndReceive(), with a callback in BeginReceive. Now all documentation says that the callback, as specified in BeginReceive, is called as soon as 'the data is received'. But this is rather vague: when exactly is that moment if you don't know how exactly that other process is providing data? One criterium is that BeginReceive()...
9
7338
by: semedao | last post by:
Hi, I am using sync and async operations on the same socket. generally I want the socket to wait on BeginReceive and to not block the object thread. but in some cases I want to stop the BeginReceive in the middle - Don't accept any data from it , and using regular Receive (I don't want the data will come to the BeginReceive byte buffer , instead of other buffer) then when I comlete some operaion , to return and call to the BeginReceive...
2
6554
by: O.B. | last post by:
In the following code snippet, the thread successfully makes it to the line where it waits for data to be received. Then the client closes the connection. The thread wakes up and returns from the WaitOne() operation. No exception is thrown when it loops and executes BeginReceive() again. The WaitOne() operation returns immediately. Thus, there's an endless loop. How does one detect that the remote client has closed the connection in...
18
4078
by: Pedro Pinto | last post by:
Hi there once more........ Instead of showing all the code my problem is simple. I've tried to create this function: char temp(char *string){ alterString(string); return string;
0
1206
by: sameh serag | last post by:
Hi all, I have a problem with .NET sockets... The code snippet bellow was working fine with .NET 2.0. After I installed .NET 3.0 it didn't work properly. private static void BeginReceiving() { //client is an instance of 'Socket' try {
0
9849
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
1
10986
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9688
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
7208
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5894
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
6094
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4727
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4308
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3324
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.