On Feb 9, 2010, at 12:59 PM, Nerius Landys wrote: >> % sysctl net.inet.udp.maxdgram >> net.inet.udp.maxdgram: 9216 >> >> However, increasing it will guarantee that you will exceed even normal jumbo >> frame size and thus depend upon IP fragmentation / reassembly for the >> traffic. I don't consider that to be a good idea, but it might be OK for >> local traffic.... > > Wow thanks. So it normally fits in 1 IP packet?
Normal use of UDP is for un-sequenced data which can fit entirely within a single packet, where some drops, out-of-order delivery, etc don't matter. (Classic example is realtime streaming, where stream-based guarantees that TCP makes is exactly what you don't want...) > (What about the MTU being like 1500 or something?) In that case, the most data per UDP packet you can send would be 1472 bytes. > What's wrong with fragmentation? Any links to explain this? If you're lucky, then it's simply much slower than using PMTU datasize. Anything in the path which does NAT, VPN tunnelling, IPsec, or the like is probably going to have to reassemble all of the fragmented packets, adjust IPs/etc for NAT or break them up again for the new MTU for the case of tunnels, refragment the packets, redo checksums, etc. Google is your friend; the first few links like: http://en.wikipedia.org/wiki/IP_fragmentation http://www.nil.si/ipcorner/IP_Fragmentation If you're not lucky, an intermediate router or firewall will simply drop the traffic entirely; maybe you will see an ICMP message, or maybe not, but it will be up to the app to deal with retransmitting the data using smaller sizes. Regards, -- -Chuck _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
