socket packet size = bandwidth?

[Zytan]

This may be the dumbest question of all time, but...

When I set the packet size, does it mean ALL packets are that size, no
matter what? Let's say the packet size is 8KB, and I send a 5 byte
"hello", will it cause 8KB of bandwidth, or 5 bytes (plus TCP/IP
packet header, as well, of course).

(Btw, I 'set' the packet size via Socket.BeginRec eive(), in the "size"
field = "The number of bytes to receive." Which seems to imply the
answer is YES.)

My concern is that I want to reduce bandwidth... but things are
'nicer' when the packet size is large so that everything comes in one
go, so I just defaulted to that, but, now b/w is an issue.

Zytan

[Zytan]

This may be the dumbest question of all time, but...

>
All due respect, it is at the very least poorly worded. :)

LOL

If you are asking a question that involves calling Socket.BeginRec eive(),
why is your hypothetical case described as "I send a 5 byte 'hello'"? Are
you asking about sending, or about receiving?

Sorry, I meant receiving 5 bytes. Most of my bandwidth is receiving
data, so this is the important part.

(I use Socket.Send(), obviously, to send data, and that takes an array
of byte, byte [], and I make that whatever size it needs to be at the
time, so I assume that this only uses as much bandwidth as is required
for the bytes and the packet header.)

And is the question about a
UDP socket or TCP socket?

TCP. (I know there's extra packets to ensure proper sequencing of
data, I'm ignoring this for now.)

If you are receiving data, you cannot rely on expecting that "everything
comes in one go", even if larger buffer sizes usually allow that to
happen. A successfully completed receive may result in anywhere from 1
byte all the way up to the buffer size actually being received for that
completion.

Right. The buffer size could be 16,384 bytes, and you send me
"hello", which is 5, and I get 5, and that was a success.

I also would not use the word "packet" to describe the size of your
buffer. At best, if you are _sending_ and you are using UDP, the buffer
length passed to the sending method would define the size of the datagram
itself. But "packets" exist at a lower level than that, and the size of
what most people are actually calling "packets" are unaffected by how an
application sends the data.

Right, if I send 100,000 bytes, it could be sent off as 4 KB packets
underneath, regardless that this is presented to me, the programmer,
as though it was sent "all as one".

If you can either clean up the question so that you're describing it more
precisely, or you can post some code that is exactly what you're talking
about, it'd probably be possible to provide a better answer. Based on
what you've asked so far, all I can say is that when you call a sending
method, the method will send exactly as many bytes as you asked it to (*)
and when you call a receiving method, the method will receive any number
of bytes between 1 and the number of bytes you told it are available in
your receive buffer.

Ok, so for Socket.BeginRec eive(), if I tell it I want to accept a
16,384 byte buffer from the internet... and some data comes in from
your PC that says "hello", I call Socket.EndRecei ve() to get the data,
which returns the number of bytes I got. Which would be 5 for
"hello", and I assume that just because the data buffer COULD accept
16,384 bytes, it would have only used 5 bytes of bandwidth (ignoring
packet headers).

Thanks, Pete!

Zytan

[Peter Duniho]

On Thu, 24 Jul 2008 13:16:55 -0700, Zytan <zy**********@g mail.comwrote:

This may be the dumbest question of all time, but...

All due respect, it is at the very least poorly worded. :)

When I set the packet size, does it mean ALL packets are that size, no
matter what? Let's say the packet size is 8KB, and I send a 5 byte
"hello", will it cause 8KB of bandwidth, or 5 bytes (plus TCP/IP
packet header, as well, of course).

(Btw, I 'set' the packet size via Socket.BeginRec eive(), in the "size"
field = "The number of bytes to receive." Which seems to imply the
answer is YES.)

If you are asking a question that involves calling Socket.BeginRec eive(),
why is your hypothetical case described as "I send a 5 byte 'hello'"? Are
you asking about sending, or about receiving? And is the question about a
UDP socket or TCP socket?

My concern is that I want to reduce bandwidth... but things are
'nicer' when the packet size is large so that everything comes in one
go, so I just defaulted to that, but, now b/w is an issue.

If you are receiving data, you cannot rely on expecting that "everything
comes in one go", even if larger buffer sizes usually allow that to
happen. A successfully completed receive may result in anywhere from 1
byte all the way up to the buffer size actually being received for that
completion.

I also would not use the word "packet" to describe the size of your
buffer. At best, if you are _sending_ and you are using UDP, the buffer
length passed to the sending method would define the size of the datagram
itself. But "packets" exist at a lower level than that, and the size of
what most people are actually calling "packets" are unaffected by how an
application sends the data.

If you can either clean up the question so that you're describing it more
precisely, or you can post some code that is exactly what you're talking
about, it'd probably be possible to provide a better answer. Based on
what you've asked so far, all I can say is that when you call a sending
method, the method will send exactly as many bytes as you asked it to (*)
and when you call a receiving method, the method will receive any number
of bytes between 1 and the number of bytes you told it are available in
your receive buffer.

(*) Exception: note that a Socket in non-blocking mode using the
synchronous Send() method may send fewer bytes than you have told it to.
You have to check the return value to see what was actually sent.

Basically, don't tell Socket to send 8K if you don't want it to send 8K.

Pete

[Peter Duniho]

On Thu, 24 Jul 2008 14:10:17 -0700, Zytan <zy**********@g mail.comwrote:

[...]
Ok, so for Socket.BeginRec eive(), if I tell it I want to accept a
16,384 byte buffer from the internet... and some data comes in from
your PC that says "hello", I call Socket.EndRecei ve() to get the data,
which returns the number of bytes I got. Which would be 5 for
"hello", and I assume that just because the data buffer COULD accept
16,384 bytes, it would have only used 5 bytes of bandwidth (ignoring
packet headers).

Yes, that's correct. The only real downside for the larger buffer is the
memory consumption locally. Generally speaking, larger buffers provided
to the Socket _improve_ performance, because you have to transition back
and forth between your application code and the network driver fewer
times. Of course, beyond a certain point (16K is a good number) you get
diminishing returns, but up to that point, larger is better.

Obviously, for modern computer systems, 16K is a trivially small buffer in
terms of memory consumption. So you might as well use something about
that size. The biggest things I'd worry about are a) if you were
allocating a lot of these buffers (handling a large number of connections,
for example), and b) keeping the buffer smaller than the threshold for
allocations winding up in the large-object heap (at 16K you'd be well
under that threshold though).

Pete

[Zytan]

Yes, that's correct. The only real downside for the larger buffer is the

memory consumption locally.

Right.

Generally speaking, larger buffers provided
to the Socket _improve_ performance, because you have to transition back
and forth between your application code and the network driver fewer
times.

Yes.

Of course, beyond a certain point (16K is a good number) you get
diminishing returns, but up to that point, larger is better.

Understood.

Obviously, for modern computer systems, 16K is a trivially small buffer in
terms of memory consumption. So you might as well use something about
that size.

I will do that.

The biggest things I'd worry about are a) if you were
allocating a lot of these buffers (handling a large number of connections,
for example), and b) keeping the buffer smaller than the threshold for
allocations winding up in the large-object heap (at 16K you'd be well
under that threshold though).

I only have one such buffer, so it's not a big deal.

Thanks for the tips, Pete!! :)

Zytan