RecvMsgUDP / SendMsgUDP

[John Dreystadt]

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

[Ian Lance Taylor]

On Mon, Jan 6, 2020 at 12:46 PM John Dreystadt <jdrey...@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

[John Dreystadt]

Sigh, sorry for getting the names wrong. Anyway, I see what Ian means about using the Control method to set an arbitrary socket option but I would not have found it without his prompting. So either we need a different procedure or better documentation. Which leads me into my proposal for changes.

Change 1, add WriteMsg and ReadMsg functions to the different socket types in x/net. This seems more in keeping with the division between the main net package and x/net. Not hard to do as the existing code for WriteMsgUDP and ReadMsgUDP can be used as a start. This would also fix the issue of handling TCP out-of-band data since TCP sockets would get the new functions.

Change 2, add GetSocketOption and SetSocketOption functions to the  same socket types in x/net. Again, not hard to do as these would be wrapper functions calling the Get and Set functions on x/net/internal/socket.Option. Documentation would be much easier than explaining how to use the syscall mechanism.

Change 3, deprecate the existing WriteMsgUDP and ReadMsgUDP functions pointing users to the new WriteMsg and ReadMsg functions. 

Any comments?

John Dreystadt