How do i avoid packet segmentation?

[owolablo]

Hi,
I'm writing a program that sends 1500 bytes of data at once, from the
client to the server. However, the packet is broken down into 3
different segments of 500 each before getting to the server. This is
detrimental to the program i'm writing as I need the server to receive
the entire 1500 bytes at once. How do I avoid this segmentation. Is it
a linux setting which I can change or is it a TCP setting? either way,
what can I do? I'm sending the packets using the C send() function.

 

[Jim Langston]

Hi,
I'm writing a program that sends 1500 bytes of data at once, from the
client to the server. However, the packet is broken down into 3
different segments of 500 each before getting to the server. This is
detrimental to the program i'm writing as I need the server to receive
the entire 1500 bytes at once. How do I avoid this segmentation. Is it
a linux setting which I can change or is it a TCP setting? either way,
what can I do? I'm sending the packets using the C send() function.

This is acutally off topic, as this is a TCP/IP problem, not a C or C++
problem. However, the problem is not with your program, but in a MTU
(Maximum Transmission Unit) somewhere between the sending and receiving
computers. It could be the sending computer, any router inbetween or the
receiving computer. So basically, the best you can do is ensure the MTU on
the sending and receiving computer are set to a high enough value and hope
for the best.

That being said, even if right now you can get it to go in one packet there
is no guarantee that tomorrow it will be received in one packet because some
router in between may have a smaller MTU. A router/computer is allowed to
break a packet into smaller chunks. This is part of the TCP/IP protocol.
It is something you have to live with and code around. It is common to send
some type of information in a packet to say how big the data actually is, so
you can piece it back together on the receiving side.

You need to start reading up on packets, etc...

Please post any follow up questions to an appropriate newsgroup dealing with
internet protocols.

 

[SirMike]

Dnia Thu, 12 Oct 2006 03:54:18 -0700, Jim Langston napisa³(a):

That being said, even if right now you can get it to go in one packet there
is no guarantee that tomorrow it will be received in one packet because some
router in between may have a smaller MTU. A router/computer is allowed to
break a packet into smaller chunks. This is part of the TCP/IP protocol.
It is something you have to live with and code around. It is common to send
some type of information in a packet to say how big the data actually is, so
you can piece it back together on the receiving side.

When you send some data, the server will get them all (can be fragmented
ofcourse). IMHO sending information about packet length in TCP/IP is
useless.

 

[Ron Natalie]

This is acutally off topic, as this is a TCP/IP problem, not a C or C++
problem. However, the problem is not with your program, but in a MTU
(Maximum Transmission Unit) somewhere between the sending and receiving
computers.

Actually, it might not even be a MTU issue. TCP/IP doesn't deal
with packets on the application side. It's a byte stream. The
size you get from a read has nothing to do with what is written
on the other side (other than that you can't obviously read more
than what was sent).

 

[Nick Keighley]

Dnia Thu, 12 Oct 2006 03:54:18 -0700, Jim Langston napisa³(a):


When you send some data, the server will get them all (can be fragmented
ofcourse). IMHO sending information about packet length in TCP/IP is
useless.

he was talking about *data length*, which is essentially Application
layer,
not packet length.

 

[KBG]

I think, it cannot break.

Regards,
Karthik Balaguru

 

[Ron Natalie]

I think, it cannot break.

I have no idea what that is supposed to mean.

As Nick and I have pointed out, there's no such
thing as a packet on the application side of
a TCP connection. It's a byte stream. There's
no guarantee that the write size has any bearing
on the read size, any more than it does in
a stdio FILE or C++ stream.

 

[Jim Langston]

Actually, it might not even be a MTU issue. TCP/IP doesn't deal
with packets on the application side. It's a byte stream. The
size you get from a read has nothing to do with what is written
on the other side (other than that you can't obviously read more
than what was sent).

A new user to TCP/IP usually does something like the file:
open the connection to the server
recieve data
Process the bytes reeived.
go back to receiving data.

That's where the problem comes in. For small packets this will work, but
even if they are small sometimes they get broken anyway. So you can't
process the data received until you piece it back together. So you have to
do more like the following.

open the connection to the server
receive data
add the data to the buffer
Is the data complete? If so process it and clear the buffer
go back to receive data

For a simple file transmission it is fairly simple, just keep adding the
data to the buffer until the socket closes. Then you have all the data.
But in a client/server or peer to peer application data is usually sent back
and forth and are usually messages. There are different schemes for keying
the end of the data. For ASCII data a simple null terminator is sufficient.
For binary data, you normally send the length of the data. That way the
application knows when the data is complete.

Yes, it's a byte stream, and needs to be treated as such. But the new user
to TCP/IP usually doesn't, they treat a packet as complete data, which it
sometimes isn't.