I am not sure that is the case. It is “known” that UDP doesn’t support OOB, mainly since it is not a stream - it is packet oriented, but also because it is not part of the specification - it would have to be an application level transport that adds that as far I understand.
That being said, I agree that the networking documentation could use some improvement - when I did the multicast for github.com/robaho/go-trader <http://github.com/robaho/go-trader> I remember it being a pain (no top-level doc on which Conn type is needed where) - but I think a lot of that is due to the cross platform nature - the local interface/network configuration has a lot of influence on how easy it is to get multicast working. > On Apr 7, 2019, at 1:08 PM, John Dreystadt <jdreyst...@gmail.com> wrote: > > Thanks, that makes sense. So the documentation here needs some work since > that is not at all clear. > > On Sunday, April 7, 2019 at 11:42:52 AM UTC-4, Pelle Johansson wrote: > Hi John, > > The oob data used in these system calls are not for communicating with the > peer. UDP doesn't support OOB data on the wire, I think the name here is a > bit unfortunate, it should rather be called "control" or somesuch. This data > is processed/created locally by the kernel and its structure is probably OS > specific. On Linux see the ip(7) man page for information about how it can be > used (search for control). > > Regards, > -- > Per Johansson > > On Saturday, April 6, 2019 at 11:24:04 PM UTC+2, John Dreystadt wrote: > I wrote some sample code (at the end of this message) to see how UDP worked > in the Go environment. And I wound up with some issues because things did not > seem to work as I expected. I am running go1.11.2 on both a Windows box and a > Ubuntu box. > > Issue 1, when I call WriteMsgUDP with both a regular buffer and an out of > band buffer, I get back the length as I expected. But I never see any out of > band data on the read side. Is this a known error or am I just missing > something? > > Issue 2, when I send a UDP message longer than the buffer at the receiving > end I get an error on the Windows side along with a bit set in flags. The > Ubuntu side does not report an error but does set a bit (but a different > one). Even more odd, the Windows side does not return the address of the > sending machine when this error occurs. While having one report an error > while not the other is not unreasonable, losing the address of the sending > machine seems really bad unless it just is not there on Windows. > > Issue 3, the documentation for the flags return from ReadMsgUDP just says > "the flags set on the message" which is pretty short and does not even > indicate who set the flags. Maybe something like "the flags are set on the > message by the network stack and are operating system dependent". > > I used two copies of the following program running to see the issues. To > replicate, first run one without any flags and then run the second with > -mode=wr . > > package main > > import ( > "errors" > "flag" > "fmt" > "net" > ) > > var rfserver = flag.String("RFS", "127.0.0.1:6000 <http://127.0.0.1:6000/>", > "Read First Server Name:Port Number") > var wfserver = flag.String("WFS", "127.0.0.1:6001 <http://127.0.0.1:6001/>", > "Write First Server Name:Port Number") > > type modeValue string > > func (mode *modeValue) String() string { > return string(*mode) > } > > func (mode *modeValue) Set(s string) error { > switch s { > case "rw": > *mode = modeValue(s) > return nil > case "wr": > *mode = modeValue(s) > return nil > default: > return errors.New("Mode must be rw or wr") > } > } > > var mode modeValue > > func main() { > mode = modeValue("rw") > flag.Var(&mode, "mode", "rw for read then write and wr for the reverse") > flag.Parse() > fmt.Println("Parameters", *rfserver, *wfserver, mode) > > rfudpaddr, err := net.ResolveUDPAddr("udp", *rfserver) > if err != nil { > panic(err) > } > wfudpaddr, err := net.ResolveUDPAddr("udp", *wfserver) > if err != nil { > panic(err) > } > var rudpaddr, wudpaddr *net.UDPAddr > if mode == "rw" { > rudpaddr, wudpaddr = rfudpaddr, wfudpaddr > } else { > wudpaddr, rudpaddr = rfudpaddr, wfudpaddr > } > pc, err := net.ListenUDP("udp", rudpaddr) > if err != nil { > panic(err) > } > > if mode == "rw" { > buffer := make([]byte, 5) > oobbuffer := make([]byte, 5) > n, oobn, flags, addr, err := pc.ReadMsgUDP(buffer, oobbuffer) > fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err) > n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer) > fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err) > n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer) > fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err) > } > > n, oobn, err := pc.WriteMsgUDP([]byte("1234"), []byte("1"), wudpaddr) > fmt.Println("n, oobn, err", n, oobn, err) > n, oobn, err = pc.WriteMsgUDP([]byte("12345"), nil, wudpaddr) > fmt.Println("n, err", n, oobn, err) > n, oobn, err = pc.WriteMsgUDP([]byte("123456"), nil, wudpaddr) > fmt.Println("n, err", n, oobn, err) > > if mode == "wr" { > buffer := make([]byte, 5) > oobbuffer := make([]byte, 5) > n, oobn, flags, addr, err := pc.ReadMsgUDP(buffer, oobbuffer) > fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err) > n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer) > fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err) > n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer) > fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err) > } > > } > > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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. For more options, visit https://groups.google.com/d/optout.
