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. John Dreystadt -- 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/5fce6cc7-8129-42a2-ade7-26c8b2d609f7%40googlegroups.com.
