I believe the only pertinent MTU in any connection is the one between *here* and *there* :p.
To be more precise, here := the node yer on and there := the next hop (usually your nearest friendly router).
Along the way, even if the packet traverses 23 hops or whatever, each MTU from point to point can be different. Hence fragmentation, flags to deal with it, and the entire TCP suite. But when coding, one needn't worry about the rest of the net, just your neighbor. You can reasonably expect each hop to be as optimized MTU-wise as it's admin can work out.
Anywhoo, I still think it might be worthwhile to test 1 server with an odd MTU between it and it's default gateway, and see if that server when used produces *way* too many fragmented packets, or just a 'reasonable' amount, whatever you want that reasonable threshold to be.
I don't know your code like you do, but kathgar was right in focusing (sp?) on packet types the server deals with that are larger than said MTU. Smaller ones dont matter, of course. So if you do a /who all, and it gens a packet say 2k large, the buffer identified by merth might cause problems do to the CPU time required to defragment and due to the various bits of network lag that slow down the receipt of all the frags of a given packet. Gotta wait for em all to be there, and all.
Just food for thought. Enjoy the meal. And I'm tired and likely blithering on too long to folks who already got the gist of the post..g'nite y'all.
|
Threaded Mode
