UDP packets lost.. truncated..: An enhancement proposal

[poth...@gmail.com]

So a lot of people seem to be running into the same issue (as did I):

• https://groups.google.com/forum/#!searchin/netty/UDP$20lost/netty/CuqtCArwRwc/HM0BupxS3BQJ
  
• https://groups.google.com/forum/#!searchin/netty/UDP$20lost/netty/YBfPLSUsSTM/OZL_1nm8pBEJ
  
• https://groups.google.com/forum/#!searchin/netty/UDP$20lost/netty/l1wUqd_G1CM/yMYEVyJ4vwAJ
  

In short, UDP packets can be lost when an appropriate buffer size is not set. This struck me as odd since the length of the packet is specified in the header of the packet. So a trivial solution would be to read the length of the packet in the header and allocate an appropriate buffer size accordingly. This would solve the missing UDP packet problem.

As blucas pointed out on IRC a solution could be:

"

(11:59:00 AM) blucas: no idea if this is right... but: https://github.com/netty/netty/blob/4.1/transport-native-epoll/src/main/java/io/netty/channel/epoll/EpollDatagramChannel.java#L544 allocate an 8 byte buffer (to read the UDP header), do a read to fill that buffer then extract the length from that buffer, then do another read to get the entire packet
(11:59:33 AM) blucas: or alternatively do a single read like we are doing now, and read the 6'th byte to get the length

"

So if this makes sense i'd be happy to do a PR for this. 

Let me know what you think,

John.

[John Poth]

Quick update. This seems not to be feasible as it is not supported by the operating system/kernel in that a specific buffer size on the socket needs to be explicitly specified (which explain why the C - >Java->Netty API is the way it is). Haven't found some resource explaining why the kernel can't/won't do UDP autotuning (performance reasons?). 

In conclusion, this is definitely not possible :)