up recv buffer size to 64k

[johnnyslush]

Noticed that this error appears on Windows with a 4kb buffer. Increasing to 64kb seems to solve the issue.

[ERROR] ResponderRecvPacket Error: 0s { code: 10040, kind: Uncategorized, message: "A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself

[willstott101]

This is surprising, do you know what's sending such a large message?

The spec states:

   Multicast DNS messages carried by UDP may be up to the IP MTU of the
   physical interface, less the space required for the IP header (20
   bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).

   In the case of a single Multicast DNS resource record that is too
   large to fit in a single MTU-sized multicast response packet, a
   Multicast DNS responder SHOULD send the resource record alone, in a
   single IP datagram, using multiple IP fragments.  Resource records
   this large SHOULD be avoided, except in the very rare cases where
   they really are the appropriate solution to the problem at hand.
   Implementers should be aware that many simple devices do not
   reassemble fragmented IP datagrams, so large resource records SHOULD
   NOT be used except in specialized cases where the implementer knows

So nothing stating we ought not handle such messages, but I'd say it's at-least unusual you're seeing any...

[willstott101]

Trust DNS has a smaller buffer than we do already: https://github.com/bluejekyll/trust-dns/blob/912c0b0a0730f0c8212b5fe43b2ef510e6f4ad21/crates/proto/src/multicast/mdns_stream.rs#L298

Then golang mdns uses a 64k buffer https://github.com/grandcat/zeroconf/blob/e4f60f8407b11e9ba16f4c4c5ad24226dd4e8519/client.go#L338

Avahi uses a dynamic buffer size (asks the kernel how big the message is): https://github.com/lathiat/avahi/blob/40f44806c5194e866ab574593891f3ea85a28e0c/avahi-core/socket.c#LL817C19-L817C27

[willstott101]

I think if you're having trouble I'll merge this, there seems to be precendent in other implementations. Thanks for the contribution.

[willstott101]

Released in 0.7.5