The docs for
The function must be called with valid byte array
buf of sufficient size to hold the message bytes. If a message is too long to fit in the supplied buffer, excess bytes may be discarded.
I have a question here: what actually happens?
I think "may be discarded" is unnecessary vague -- that's udp socket, so the excess data will be discarded, won't it? It seems this wording is just inspired by manpages, where "may" is more warranted as, I think, one can
recv on a TcpSocket?
And the second thing: suppose truncation happens, would I get an Ok or Err here?
(secret agenda: it seems there's an opportunity to improve the docs here, they at least should mention that 65k buffer should be enough).
I'm not sure we should think of truncation as an error here. If you get the number of bytes you ask for where is the error? Even if any extra bytes are discarded.
It is definitely discarded, otherwise it wouldn't be UDP. I agree with your reasoning as to why the "may" is there - it is probably lifted from the manpage for
read (which in general may discard, depending on what the file-descriptor points to).
If it follows
read semantics, then it should be an
Ok, with the wrapped value being the size of the buffer (since the message was truncated).
I'd go so far to say that 2K is also enough, since for most systems, the size of the datagram is limited by the Ethernet layer's MTU (which is 1500, so removing the header length, it's even less).
On internet traffic Google uses 1500 bytes for receive buffer which is eithernet minimum MTU and 1200 bytes for send buffer which is IPv6 minimum MTU. But to make sure discard will never happen even 2k is not enough. For example traffic between AWS EC2 instances within same VPC tends to use jumbo frame which has MTU of 9001 bytes.
Hm, is this really so? I think packets larger than MTU can get fragmented. That is, as a sender, you should try to send small enough datagrams to avoid fragmentation. However, as a receiver, you can’t really assume that that would be the case.
I don't think UDP supports fragmentation - TCP does however.
Hm, fragmentation is a feature of IP, so UDP doesn’t need to support it directly I think? Or does it explicitly set the “don’t fragment” bit in IP?
Oh right! Well, that means that UDP datagrams must be re-assembled at the IP layer before being delivered to the UDP layer, right? So it shouldn't matter?
Although that means that MTU doesn't really limit the UDP packet size.
What I meant is that TCP, being stream oriented, can send whatever it feels like in a single packet. UDP being datagram oriented cannot do that.
This is correct,
UDP can fragment on the IP layer and be reconstructed (if all fragments survive).
(Jumbo UDP packets can also be larger than 64k, but I think that's pretty niche application. However, any "recommended" buffer size would need a number of caveats anyway, as the actual, practical limit is application/protocol specific, as others noted. Probably the best advice is "read up on your use case".)