The maximum transmission unit (MTU) is dependant on the connection between the two hosts. It may even change at runtime (if the net has to compensate for high traffic).

As far as I know, there is no guarantee for a MTU size, especially over the internet. Unless you know about the network between source and target, you'll have to detect the MTU at runtime.
Furthermore, UDP packets are never fragmented unless I'm mistaken. They are eiter transmitted or discarded. Also, fragmenting in general is no longer widely supported and will be gone with Ipv6 at the latest. The protocoll implementation is supposed to use the correct MTU nowadays.

[edited by - BitMaster on March 8, 2004 7:43:09 AM]

quote:As far as I know, there is no guarantee for a MTU size, especially over the internet. Unless you know about the network between source and target, you''ll have to detect the MTU at runtime.

Actually, IP guarantees packets of 576 bytes or less will never get fragmented by the network. So you could say this is the largest ''guaranteed'' MTU, even without knowing the route between endpoints. Now, the UDP packet can still get dropped due to congestion, but it won''t be dropped as a result of fragmentation/missing fragments.

quote:Furthermore, UDP packets are never fragmented unless I''m mistaken.

Sort of... UDP never fragments, but IP does. Therefore at the IP level your UDP packet can be munched. The UDP layer on the recieve side either gets all of the data that was sent, or it discards the packet entirely. I believe there is also a "don''t fragment" flag that can be set for IP, however packet size is still limited by path MTU.

Typically, anything less than 1472 bytes (user data MTU on ethernet) is reasonable even across the Internet. But if you need to play it safe, go with the smaller 512 data size.

good luck

While it is true that pakcets can be fragmented, a lot of routers even today don't do it and instead simply discard a packet. And in IPv6, fragmenting isn't implemented anymore.

[edited by - BitMaster on March 9, 2004 4:43:46 AM]

it is about 64K bytes

From RFC791 :
<I>Every internet module must be able to forward a datagram of 68
octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets.
Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled.
</I>

from RFC 991 ("The Official Arpa Internet Protocols"):

quote:The default IP Maximum Datagram Size is 576.

Although the IP spec(rfc791) does give a slightly more intriguing (and admitedly, older) discussion...

Comer (Internetworking w TCP/IP vol. 1) says:

quote:A router must always handle datagrams of up to 576 bytes, while Hosts are required to accept (and reassemble if necessary) datagrams of at least 576 bytes).

Notice the use of language like "router/host" and "up to/at least".

Stevens says numerous things about the 576-byte limit, and since I''m lazy I won''t retype it all. (see TCP/IP Illustrated vol1 sections 3.2, and 11.5 through 11.10)

Normally I''d say "the RFCs are the bottom-line authority", however, my experience as a protocol implementer is that the standard references (aka "Jacobson,Comer and Stevens") usually take precendence. Many older applications (DNS, TFTP and others) internally limit their datagram size to 512 or less to avoid this 576 limit. It is very possible that you can encounter a path MTU that is much larger than 576 (perhaps 1500 ala ethernet).

When considering message sizes, don''t forget that some protocols have a minimum message/datagram/frame size also. If you are going out of your way to create small messages, you might be hurting your performance, as the message typically gets padded to the protocols ''minimum'' size anyways. Ethernet is a good example - the minimum frame size on ethernet is 46-bytes.

Good luck, hope you guys find at least something useful from the conversation...