tags:

views:

354

answers:

5

What is the maximum packet size for a TCP connection or how can i get the maximum packet size?

A: 

Generally, this will be dependent on the interface the connection is using. You can probably use an ioctl() to get the MTU, and if it is ethernet, you can usually get the maximum packet size by subtracting the size of the hardware header from that, which is 14 for ethernet with no VLAN.

This is only the case if the MTU is at least that large across the network. TCP may use path MTU discovery to reduce your effective MTU.

The question is, why do you care?

WhirlWind
That'll only get you the maximum packet size on the first link. As far as I know, any other node along the route is allowed to not like large packets and it might get split up anywhere along the path.
Matti Virkkunen
Yup, that's true... so your question is good -- why would you want this?
WhirlWind
I want to transmit videos/images over a lan connection
Alexa
Since TCP is stream-oriented, why does this matter?
WhirlWind
A: 

There're no packets in TCP API.

There're packets in underlying protocols often, like when TCP is done over IP, which you have no interest in, because they have nothing to do with the user except for very delicate performance optimizations which you are probably not interested in (according to the question's formulation).

If you ask what is a maximum number of bytes you can send() in one API call, then this is implementation and settings dependent. You would usually call send() for chunks of up to several kilobytes, and be always ready for the system to refuse to accept it totally or partially, in which case you will have to manually manage splitting into smaller chunks to feed your data into the TCP send() API.

Pavel Radzivilovsky
TCP has packets, as well as a packet header, part of which overlaps the IP header. Just because you're not supposed to see it doesn't mean it doesn't exist. TCP is *always* done over IP. You can't do it without IP because the headers overlap.
WhirlWind
A: 

At the application level, the application uses TCP as a stream oriented protocol. TCP in turn has segments and abstracts away the details of working with unreliable IP packets.

TCP deals with segments instead of packets. Each TCP segment has a sequence number which is contained inside a TCP header. The actual data sent in a TCP segment is variable.

There is a value for getsockopt that is supported on some OS that you can use called TCP_MAXSEG which retrieves the maximum TCP segment size (MSS). It is not supported on all OS though.

I'm not sure exactly what you're trying to do but if you want to reduce the buffer size that's used you could also look into: SO_SNDBUF and SO_RCVBUF.

Brian R. Bondy
+3  A: 

The absolute limitation on TCP packet size is 64K (65535 bytes), but in practicality this is far larger than the size of any packet you will see, because the lower layers (e.g. ethernet) have lower packet sizes.

The MTU (Maximum Transmission Unit) for Ethernet, for instance, is 1500 bytes. Some types of networks (like Token Ring) have larger MTUs, and some types have smaller MTUs, but the values are fixed for each physical technology.

Ether
"But the values are fixed for each physical technology" -- this isn't true. Ethernet used to have a maximum MTU of 1500, but you could use a lower one. With the advent of jumbo frames, there is no real specified maximum, and the maximum varies depending on the hardware and driver.
WhirlWind
@Whirl: true, they are configurable, but generally they aren't; "configurable" is subjective because one would have to delve into the kernel to do so. It's not something one can tinker with at the application level, which is where the OP seems to be at.
Ether
+1  A: 

This is an excellent question and I run in to this a lot at work actually. There are a lot of "technically correct" answers such as 65k and 1500. I've done a lot of work writing network interfaces and using 65k is silly, and 1500 can also get you in to big trouble. My work goes on a lot of different hardware / platforms / routers, and to be honest the place I start is 1400 bytes. If you NEED more than 1400 you can start to inch your way up, you can probably go to 1450 and sometimes to 1480'ish? If you need more than that then of course you need to split in to 2 packets, of which there are several obvious ways of doing..

The problem is that you're talking about creating a data packet and writing it out via TCP, but of course there's header data tacked on and so forth, so you have "baggage" that puts you to 1500 or beyond.. and also a lot of hardware has lower limits.

If you "push it" you can get some really weird things going on. Truncated data, obviously, or dropped data I've seen rarely. Corrupted data also rarely but certainly does happen.

Nektarios