Hi Peancor,
UDP sends datagrams as opposed to being a stream protocol like TCP. When you send UDP packets that are larger than the maximum transmission size of the network (standard Ethernet uses 1500 bytes) the IP layer has to fragment those packets into multiple IP packets. Then on receiving side, the receiver's IP stack needs to re-assemble the fragments before delivering them up to the UDP socket/listener. Generally it is considered bad practice to send UDP packets larger than the 1500-byte ethernet MTU since IP fragment reassembly is a CPU intensive operation compared to unfragmented packets. Additionally, you increase the unreliability of the system dramatically since a single missing fragment will cause your entire UDP packet to be dropped. Protocols like TCP do their own internal fragmentation in a much more efficient manner than IP fragmentation (not to mention TCP adds reliability on top of it).
I may be wrong, but I don't believe there is necessarily a technical reason (at least today) for limiting UDP packets at 8192 bytes. Once you pass 1500 bytes and have to be fragmented, there shouldn't be too much difference all the way up to the 64K UDP limit. However, some quick googling indicates some [probably older] TCP/IP stacks did not reassemble UDP datagrams over this size. Another idea is that many network interfaces with hardware offloading either don't handle re-assembly or may have their own limits and have to fall back to software once those limits are exceeded.
My suggestion would be that if everything is working fine and you don't expect changes in network topology, I would not worry about exceeding 8192 bytes. However, just realize the limitations of using UDP once you start fragmenting packets.
Hope this helps,
-Eric G
