socket stream

Hello guys,

Under C, I set the tcp windows size buffer (input and output) with
setsockopt to a 128k size...(example)

My client "send()" 256ko of datas to my waiting socket

On the server side, I wait with a "recv(sock, buf, 256000,0)" like...

But now, my tcp windows size seems to be "too small" to handle all the 256ko
no ?
What happens is this case ?
I mean, the recv function (internally) will fetch my data in two passes ?

thanx

On Thu, 19 Aug 2004 21:52:27 +0200, captain biceps <spe@x-media.fr> wrote:

> But now, my tcp windows size seems to be "too small" to handle all the
> 256ko no ? What happens is this case ? I mean, the recv function
> (internally) will fetch my data in two passes ?

You will get the data in whatever size chunks you get it in. It will
take however many passes it takes. The TCP window size doesn't
guarantee anything in that regard.

In general you should not ever assume that TCP will deliver data in any
particular chunk size, because sooner rather than later your assumption
will be wrong. It is a stream protocol, not a datagram protocol. Think
of TCP as a serial port with unknown and jittery timing.

What you need to do is create some way of telling when you have received
a complete message. Some options are a header with a byte count, a
record separator (e.g. newline), or inserting special data of some kind
in the stream. However you do it the point is that you need to be able
to find the start and end of a message independent of how many times you
have to call read() to get the whole thing.

Or you could use UDP with your own retry mechanism.


--
-| Bob Hauck
-| To Whom You Are Speaking
-| http://www.haucks.org/

"captain biceps" <spe@x-media.fr> wrote in message
news:cg30dq$30a$1@news-reader3.wanadoo.fr...
> Hello guys,
>
> Under C, I set the tcp windows size buffer (input and output) with
> setsockopt to a 128k size...(example)
>
> My client "send()" 256ko of datas to my waiting socket
>
> On the server side, I wait with a "recv(sock, buf, 256000,0)" like...
>
> But now, my tcp windows size seems to be "too small" to handle all the
256ko
> no ?
> What happens is this case ?
> I mean, the recv function (internally) will fetch my data in two passes ?
>
> thanx

Socket buffer size does not imply how much data you can send or receive. It
implies how much data one host can push to another host before getting an
acknowledgement from other(this is a TCP level ack which is end-to-end).

Say ur client is sending 256k and server is busy with some other process.
Now the client can send upto 128k of data as that is what the server
advertised as buffer size (even if client has a buffer size of 256k). After
sending the 128k the client must wait till it receives an acknowledgement
from server saying this much more buffer has been freed e.g. 64k in which
case client can send 64k more.

Ofcourse in real world, the server would process these bytes according to
its work load and get back to client as and when received bytes are
processed, letting client know that some more buffer has been freed. Please
refer to sliding window protocol in Data Communications by Stallings or
Computer Networks by Tanenbaum for better description.

Thus based on how fast the server can process the received bytes and free
the buffer, you might have anywhere from 2 to unknown number of phases.

This protocol is an end-to-end protocol and is layered upon the others
including link layer. This protocol works same way irrespective of the type
of network you use. Lets see as an example how this works on top of
ethernet, which employs a packet size of 1500 bytes. When the client says it
wants to send 128k (it cannot offer to send more than that), the network
interface splits this 128k into packets each of size 1500 bytes and sends
them on network. These link layer packets are governed by a hop-based flow
control where an intermediate switch/router/host mandates how many packets
your host can send before receiving an acknowledgement.