Re: Fundamentals question, is this how it works?
- From: "Michael K. O'Neill" <MikeAThon2000@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 20 Jul 2006 16:33:34 -0700
"Daniel" <DanielV@xxxxxxxxxxxxxxxx> wrote in message
news:uDfBVwCrGHA.4864@xxxxxxxxxxxxxxxxxxxxxxx
Heybytes
With a tcp stream socket what happens when it is reading say 4000bytes and
495 bytes come in?
I am finding when i add a delay in my reading i always read my data
correctly. If i let it run at full speed it gets stuck. I am using
asynchornous sockets.
On my understanding is this right, say i have a receive buffer of 1024
and i send 2048 bytes, then straight after i send 400 bytes:processes
1) Client receives 1024 bytes of data from original 2048 sent, and
it
2)After client reads all the data it receives the next 1024 bytes, and
processes it
3) then it reads the first 400 bytes and processes it.
Am i right in that it queues up that way?
No, this is not the way it works.
TCP is a stream-based protocol, which means that it ignores any attempt (on
the sending side) to somehow group the sent data into "messages" or
"packets" or whatever you want to call them. If the sending side sends 2048
bytes, then (assuming a buffer large enough) the receiving side might get
all 2048 bytes in one call to recv(), or it might need many calls to recv()
before all 2048 bytes are sent. If the sending side sends 2048 bytes and
then sends another 400 bytes, then the receiving side might get all 2448
bytes in one call to recv() or (again) it might need many calls to recv()
before all 2448 bytes are received. Moreover, the groupings by which these
bytes are received will generally ignore the fact that 2048 bytes were sent
first followed by 400 bytes, so a first call to recv() might get 1531 bytes
(arbitrary number, just for example's sake), a second call to recv() might
get 814 bytes, and a third call might get the remaining 103 bytes.
The only thing that TCP guarantees is that the bytes will be received in the
correct order. TCP does not guarantee that the bytes will be received in
the same groupings as when they were sent. In fact, in a degenerative case
that probably would never occur in practice (but is still theoretically
possible), only one single byte at a time might be retrieved by each call to
recv().
And why if i slow down the readingbut
does it become reliable but if i let it read at full speed it gets stuck.
When i say stuck i mean it ignores new data coming in. So it does this,
this is accurate to my real situationanyway
1) Reads 425 bytes
2) now no longer reads any new data
Is it possible it is trying to read too quick? since it is in a loop
surely it has to finish reading the first before it can continue anyhow?
Generally, situations like this are caused by code that assumes that TCP
preserves groupings. TCP itself is not stuck. However, because of the
mistaken assumption, the code has encountered an unexpected situation, such
as looking for a NULL terminator in c-style string, and then discarding
everything after that. This is a mistake because TCP might have delivered
part of the next string, such that the code discards valid data.
.
- Follow-Ups:
- Re: Fundamentals question, is this how it works?
- From: Daniel
- Re: Fundamentals question, is this how it works?
- References:
- Fundamentals question, is this how it works?
- From: Daniel
- Fundamentals question, is this how it works?
- Prev by Date: Fundamentals question, is this how it works?
- Next by Date: Re: Fundamentals question, is this how it works?
- Previous by thread: Fundamentals question, is this how it works?
- Next by thread: Re: Fundamentals question, is this how it works?
- Index(es):
Relevant Pages
|
Loading
