Hacker News new | past | comments | ask | show | jobs | submit login
Everything you ever wanted to know about UDP sockets but were afraid to ask (cloudflare.com)
69 points by jgrahamc on Nov 25, 2021 | hide | past | favorite | 8 comments



Author here. There is surprisingly little documentation about UDP. I mean, there is tons of tutorials showing sendto/recvfrom, but that's not enough.

Doing basic CMSG operations in some programming languages is remarkably hard. Using IPv4-mapped-IPv6 addresses is little known. Most programming languages and frameworks are unaware of AF_UNSPEC. And so on.

Not everybody will end up doing the low level socket juggling, but I think it's at least good to know the capabilities of the operating system.


Thanks for the quality content.

You are absolutely right, there is very little documentation on UDP (probably because it was a pariah protocol reserved for "weird" things like DNS and SIP).

Now that UDP is becoming the mainstream, any documentation is highly appreciated.

Any chance of an article explaining difference in UDP handling between Linux and Windows? I've seen some weird client UDP issues on Windows side some time ago, and (unsurprisingly) found zero documentation explaining these issues.


Thanks, bookmarking this for whenever I stumble back into doing recreational gamedev.


Thanks for the article. Would you mind to explain why for the second case in the table (connected socket with bind() and connect()) we need to use recvfrom() instead of recv()?


It's mentioned in the prose.

After bind() before connect() there is a race condition, you can receive packets going to unconnected bind() socket, right?

  bind(0.0.0.0, 1234)
  ## packet to port 1234 arrives NOW
  connect(1.1.1.1, 53)
If you recv() you will not be able to figure out if the received packet came from 1.1.1.1 or someone else. Therefore in case of bind+connect you must use recvfrom and validate source of the packet, at least for early packets on the socket.


Ah so it means "filter the source IP/port when receiving early packets on the connected socket" is done by recvfrom()? I was misunderstood that it is done by some fancy iptable/epbf rule :) Thanks for clarification.


The image on the page is http:// it's giving an insecure warning.

I mean it happens, but on a high-profile site like cloudflare?


I'm not seeing anything http:// when I load the page. Which image are you referring to?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: