should clients always use recv & send, servers use recv_from & send_to?

[cakekindel]

No description provided.

[cakekindel]

Everyone always uses recv_from and send_to. the connect syscall seems to just keep some internal state of "this is who send and recv are dealing with." the only caveat with this change is that clients need to filter received dgrams by the socket of the server they're talking to (to prevent a local socket being used for conversations with 2 different servers from mixing up their responses)

[chrysn]

Just using send_to and recv_from makes implementations prone to sending responses from different IP addresses than the request was sent to. There's an entry in the CoAP FAQ detailing the issue.

[cakekindel]

Good point - the implementation guidance rfc points out that one should either read the destination socket, bind to it, and send the reply via that socket - or just plain don't bind to INADDR_ANY. The former would be a bit of work but would prevent users from encountering a difficult-do-debug gotcha. I'll make a new issue outlining this work

[chrysn]

There is also the option of using IPV6_RECVPKTINFO, which works quite well also for IPv4 on OSes that allow V4MAPPED addresses. (On systems that only support V4 through the legacy stack, there's also a corresponding socket option, I just never bothered with them, as V4MAPPED works well even if you only want to bind to a V4 address).