Re: CAsyncSocket and receive
From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 05/14/04
- Next message: Joseph M. Newcomer: "Re: CAsyncSocket and receive"
- Previous message: Jeff Partch: "Re: Scrollbars of a multiline editbox aren't refreshed"
- In reply to: Sims: "CAsyncSocket and receive"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 14 May 2004 14:52:11 -0400
Note that how much data is sent is up to you, and you have to figure out what that is.
If you do the receive as shown, you will receive between 0 and 3 bytes. That is the ONLY
guarantee receive gives you. Generally, 0 bytes means the connection has been cleanly
closed on the other side. But you could receive 1, 2 or 3 bytes. Go back and check the FSM
model I showed in the earlier post on how to parse an input stream.
If you want to know the length of a packet, it is up to you to determine how you are going
to do that. Some people put a binary count in front of each packet (remembering that you
will read this possibly in pieces), often using Network Standard Byte Order to represent
it; or you may put a fixed number of digits expressed as text (I did one where every
packet started with four digits, allowing packets of length 0001 to 9999, where I used
0000 to indicate end-of-transmission), or you may simply read bytes until you see a
designated character, such as a newline or some other known delimiter.
But when you do a receive of size n, then the ONLY thing you know is that you will receive
between 0 and n bytes. Any correlation of this count to whatever you sent is purely
coincidental, except that you are guaranteed that the sum of all characters received will
be the sum of all characters sent, and the characters will be ultimately received in the
correct order with no drops and no duplicates. But believing that if you send 512 bytes
that you will receive 512 bytes is incorrect. You will receive however many bytes the
network feels like delivering.
Considerations such as the MTU (Maximum Transmission Unit) of intervening network layers,
the use of Nagle's Algorithm (which buffers packets up on the sender side), buffer
boundaries (which are sometines outside your control), the amount of internal buffering
consumed by other network transfers which are happening, and a few other considerations
mean that there is no concept of "packet" in TCP. There is only "stream". Any
interpretation of "packet" you wish to impose is something you do on your own, and you
have to always think of the fact that any given receive will receive an unpredictable
number of bytes, which might, on a good day, under restricted circumstances, just possibly
appear to resemble your transmission send size. But if you see this happen, it is the
purest of coincidences.
joe
On Fri, 14 May 2004 17:01:32 +0100, "Sims" <siminfrance@hotmail.com> wrote:
>Hi,
>
>I have my client and my server working ok.
>I can set my OnReceive to receive data but how do i know how much data is
>been sent?
>
>so when i do
>
>BYTE buf[3]
>receive( buf, 3*sizeof(byte) );
>
>it works fine but what if I do not know the size of the data been passed?
>(If the client passes 50 bytes how do I know what to read?).
>
>Many thanks
>
>Sims
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
- Next message: Joseph M. Newcomer: "Re: CAsyncSocket and receive"
- Previous message: Jeff Partch: "Re: Scrollbars of a multiline editbox aren't refreshed"
- In reply to: Sims: "CAsyncSocket and receive"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
