By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,640 Members | 2,279 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,640 IT Pros & Developers. It's quick & easy.

When exactly is BeginReceive on a socket considered completed?

P: n/a
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() is considered completed (and thus the
callbask is called) when the buffer in the state object is filled upto the
specified buffersize. But what if the 'delivering' process is feeding data
in unknown quantities and in an irregular pattern? For instance, if it first
delivers 100 bytes consecutively, and then there is a time interval of 1
millisecond and another 200 bytes follow: does BeginReceive complete with
100 bytes of incoming data? Or 300?

Thanks for any insight.

Marcel Brekelmans
Aug 30 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
In article <f4********************@giganews.com>, Marcel Brekelmans
wrote:
But what if the 'delivering' process is feeding data
in unknown quantities and in an irregular pattern?
Data arrives in packets that are split based on how much data the
sending process supplies at a time but that may also be split while
they're in transit. As far as the receiving application is concerned,
the receive completes when a LAN packet is received. If there's more
data, that is handled on the next receive.

If you're using TCP, the protocol is designed to handle a logically
continuous stream of octets/bytes without marked message start/finish.
It's important to understand that packets may be arbitrarily split
while in transit (or for that matter, by one of the end point hosts).
Applications typically split data into messages by including either a
message length or an end of message flag.

Hope this helps.

Mike

Sep 1 '06 #2

P: n/a
As Mike points out, you can't count on anything. You can only count on 1
byte or 0 (i.e. closed). You need to "know" how many to expect and loop. I
find the best way to do this is by prepending a length (or fixed length
header that includes the data length) to the message, so then you know when
the message is received. Appending a marker at the end can be problematic
as you need to pick a marker that will never appear in the data stream.
With a prepended Len, you don't need to worry about it.

--
William Stacey [MVP]

"Marcel Brekelmans" <ma****@marcel-art.comwrote in message
news:f4********************@giganews.com...
| 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() is considered completed (and thus the
| callbask is called) when the buffer in the state object is filled upto the
| specified buffersize. But what if the 'delivering' process is feeding data
| in unknown quantities and in an irregular pattern? For instance, if it
first
| delivers 100 bytes consecutively, and then there is a time interval of 1
| millisecond and another 200 bytes follow: does BeginReceive complete with
| 100 bytes of incoming data? Or 300?
|
| Thanks for any insight.
|
| Marcel Brekelmans
|
|
Sep 1 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.