Conversation

Notices

1. Embed this notice
   William D. Jones (cr1901@mastodon.social)'s status on Monday, 09-Feb-2026 17:17:28 JST William D. Jones

   #lazyweb I'm sorry if this is a stupid q, but... if you do a _single_ sendto call, you can send a single UDP packet of up to 65535-minus-some-change, and IP frag/reassembly will ensure you either receive it in order, or not at all?

   I.e. it's only with multiple sendto calls that you start having problems with UDP packets being received out of order?

   (And if you do a single sendto call, the larger the packet, the more likely it'll be dropped due to reassembly timeout?)

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Monday, 09-Feb-2026 17:17:23 JST Rich Felker

     in reply to

     • Erin 💽✨

     @cr1901 @erincandescent Keep in mind this is IPv6 incompatible unless you keep the limit below the minimum allowed MTU. Thus something of a dead end.

   • Embed this notice
     William D. Jones (cr1901@mastodon.social)'s status on Monday, 09-Feb-2026 17:17:24 JST William D. Jones

     in reply to

     • Erin 💽✨

     @erincandescent I wrote a UDP layer for an existing RPC library. I assume that any RPC fits within a single UDP packet, any packet can be lost, and that any RPC call is idempotent (so I don't have to care about ACKs being lost). But out-of-order is not something I handle currently (the RPC layer has a user field that could allow it tho).

     I was just mulling over increasing the arbitrary max payload len from 128 to some larger number < ~65536 that's still likely to be received.

   • Embed this notice
     Erin 💽✨ (erincandescent@akko.erincandescent.net)'s status on Monday, 09-Feb-2026 17:17:26 JST Erin 💽✨

     in reply to

     • Erin 💽✨

     @cr1901 Note: if sent with the Don’t Fragment bit (IPv4) or over IPv6, the packet might get dropped in route because the MTU was exceeded after a certain hop. An ICMP packet should get sent back (emphasis on the should, ICMP has a bit of a habit o getting lost down blackholes) to inform the kenrel of the path MTU but if it doesn’t you’ll just have a blackhole

   • Embed this notice
     Erin 💽✨ (erincandescent@akko.erincandescent.net)'s status on Monday, 09-Feb-2026 17:17:28 JST Erin 💽✨

     in reply to

     @cr1901 yes, yes and yes.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Monday, 09-Feb-2026 17:27:12 JST Rich Felker

     in reply to

     • Erin 💽✨

     @erincandescent @cr1901 Oh? How does it work? Sender needs to do MTU discovery and retransmit fragmented?

   • Embed this notice
     Erin 💽✨ (erincandescent@akko.erincandescent.net)'s status on Monday, 09-Feb-2026 17:27:13 JST Erin 💽✨

     in reply to

     • Rich Felker

     @dalias @cr1901 IPv6 has fragmentation. Its just that routers don’t do it.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Monday, 09-Feb-2026 17:31:55 JST Rich Felker

     in reply to

     • Erin 💽✨

     @erincandescent @cr1901 But this fragmentation really happens at the network stack layer not the application layer? I wasn't aware of that. Does it really work in practice? IIRC I could never get Wireguard working without inner MTU smaller than outer MTU on v6.

   • Embed this notice
     Erin 💽✨ (erincandescent@akko.erincandescent.net)'s status on Monday, 09-Feb-2026 17:31:57 JST Erin 💽✨

     in reply to

     • Rich Felker

     @dalias @cr1901 yes. well it doesn’t really retransmit, the packet will get dropped but it’ll now know the path mtu so it can do sender-side fragmentation.