On Mon, Jan 6, 2020 at 12:46 PM John Dreystadt <jdreyst...@gmail.com> wrote: > > I noticed that the documentation for net.RecvMesgUDP and net.SendMesgUDP > seemed a bit odd because it referred to “out of band” for some of the > parameters being passed and some of the return values. This caused me to look > closely at these two functions and here are the results of my research. > First, the documentation uses “out of band” when most other documentation, > such as the Linux docs for recvmsg(2), use either “control messages” or > “ancillary information” for the same fields. This may confuse newcomers to > these functions as “out of band” looks like a reference to the TCP concept of > “out of band” which is specific to TCP and not present in UDP. Second, the > “out of band” fields in question are not useful unless certain socket options > are set which cannot be done using the functions available in the “net” > package. Third, the “golang.org/x/net” package provides access to most of the > socket options in question but not all (the socket option IPPROTO_IP, > IP_PKTINFO is not available). There are functions in > “golang.org/x/net/internal/socket” for both setting arbitrary socket options > and calling recvmsg/sendmsg (still assuming Linux here but Windows just has > different names). These cannot be called by user programs because they are in > an “internal” package. Fourth and last, I don’t see any way to determine if a > read of a TCP socket (not UDP this time) has returned out of band > information. In C, I would use recvmsg and check the returned flags for the > bit MSG_OOB but there is no RecvMesgTCP. > > I have a proposal for changes but I wanted to see if anyone disagreed with > the above. I would be especially interested in anyone using these two > functions today.
I guess you're talking about net.UDPConn.WriteMsgUDP and net.UDPConn.ReadMsgUDP. I agree that on Unix systems that "out of band" data is normally called "ancillary data," and we should change the net package docs. User programs can set arbitrary socket options by using net.UDPConn.SyscallConn to get a syscall.RawConn and calling the Control method. But I agree that that procedure needs to be better documented somewhere. I'm kind of surprised that there is no way to handle TCP out-of-band data but I admit that I don't see one. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVT9PRzqq7X8L%2BLzQPD-2YBigN4OEcdHZeoOzWbhH7CRQ%40mail.gmail.com.
