network read question

[parez]

Hi,

When does the socket (server) know when to stop reading.

e.g.

if i have a buffer = 25K

and do networkStream.write twice.. what will the server read? 25k or
50K?

And should i send a message length for every message i send? and make
the server read specified number of bytes?
networkStream.Write(buffer, 0, buffer.Length);
networkStream.Write(buffer, 0, buffer.Length);
**********************Server Code ***********************************
Socket newsock = new
Socket(AddressFamily.InterNetwork,
SocketType.Stream, ProtocolType.Tcp);

newsock.Bind(ipep);
newsock.Listen(10);
Socket client = newsock.Accept();
data = new byte[64000];

recv = client.Receive(data);

**********************************************

[Peter Duniho]

On Wed, 09 Apr 2008 15:03:38 -0700, parez <ps*****@gmail.comwrote:

When does the socket (server) know when to stop reading.

e.g.

if i have a buffer = 25K

and do networkStream.write twice.. what will the server read? 25k or
50K?

If you write 50K, the server will eventually read 50K. However, there is
no way to predict in advance how the server will read that 50K. It could
read a single byte 50 thousand times, it could read 5 bytes ten thousand
times, it could read 50K once, it could read 10K, 10K, 25K, then 5K, it
could...

Any possible permutation is possible.

And should i send a message length for every message i send? and make
the server read specified number of bytes?

With TCP (which is what NetworkStream implies), you _must_ provide some
mechanism to allow the recipient to know how long the transmission is.

In the simplest case, the transmission is "complete" when the connection
is closed. For some protocols, that's sufficient. For higher-performance
protocols, where you want to leave the connection open between your
logical messages, you need to incorporate some means of delimiting
messages. Preceding each logical message with a byte count is indeed a
legitimate and common way to accomplish that.

Pete

[parez]

On Apr 9, 6:20 pm, "Peter Duniho" <[e-mail]>
wrote:

On Wed, 09 Apr 2008 15:03:38 -0700, parez <[e-mail]:

When does the socket (server) know when to stop reading.

e.g.

if i have a buffer = 25K

and do networkStream.write twice.. what will the server read? 25k or
50K?

If you write 50K, the server will eventually read 50K. However, there is
no way to predict in advance how the server will read that 50K. It could
read a single byte 50 thousand times, it could read 5 bytes ten thousand
times, it could read 50K once, it could read 10K, 10K, 25K, then 5K, it
could...

Any possible permutation is possible.

And should i send a message length for every message i send? and make
the server read specified number of bytes?

With TCP (which is what NetworkStream implies), you _must_ provide some
mechanism to allow the recipient to know how long the transmission is.

In the simplest case, the transmission is "complete" when the connection
is closed. For some protocols, that's sufficient. For higher-performance
protocols, where you want to leave the connection open between your
logical messages, you need to incorporate some means of delimiting
messages. Preceding each logical message with a byte count is indeed a
legitimate and common way to accomplish that.

Pete

Thanks..
I have a situation where i sending a approx 50k message. the server
is reading it into a 128 k buffer. but it only 2k (most of the times)
and the number varies.. the server program is written so that it
quits reading after the first read
(max size of the message is apprx 65K). So i will have to send the
first x bytes as message length?

Coming back to the original question, there is no way of certainly
knowing how many bytes will the server read in one go...

[Peter Duniho]

On Wed, 09 Apr 2008 15:40:34 -0700, parez <ps*****@gmail.comwrote:

I have a situation where i sending a approx 50k message. the server
is reading it into a 128 k buffer. but it only 2k (most of the times)
and the number varies..

Sounds about right. Over the Internet, the maximum transmission unit
(MTU) is just under 2K. So it's not uncommon to receive data in chunks of
that size (i.e. just under 2K). Different segments along the route may
have different MTUs and other factors can also cause the actual data
delivered to arrive in varying lengths. But it's not unusual to see sizes
in that ballpark.

the server program is written so that it
quits reading after the first read

Well, that's a bug.

(max size of the message is apprx 65K). So i will have to send the
first x bytes as message length?

You don't have to. But you do have to do _something_ like that. Sending
the message length first is a common solution, but it's not mandatory.
The only thing that is mandatory is that the recipient can reliably
delimit the incoming data.

Coming back to the original question, there is no way of certainly
knowing how many bytes will the server read in one go...

No. There's not.

Pete

[Ignacio Machin ( .NET/ C# MVP )]

I have a situation where i sending *a approx 50k message. the server
is reading it into a 128 k buffer. *but it only 2k (most of the times)
and the number varies.. the server program is written *so that it
quits reading after the first read

Do you have the code of the server?
Remember that even as you say read X bytes you will get only the
bytes that were read already. The server usually works in a loop.

(max size of the message *is apprx 65K). So i will have to send the
first x bytes as message length?

Does the server support that?
If not the length will become part of the data.

Coming back to the original *question, *there is no way of certainly
knowing *how many bytes will the server read in one go...

Nop