Sorry it took so long for this post, other things intervened. Anyway, quick responses to the three people who commented.
Shulhan, there is a better mechanism in Go than resetting the buffer. Have a second variable, say "var message []byte", and then after the call to ReadMsgUDP add this line "message = buffer(:n)" and the program can use message without the cost of any type of reset on the buffer. The oobbuffer is different in that it may be used as input and should be reset as you say. But most applications should just past nil and ignore it. Pelle Johansson, I think this name confusion is more than a bit unfortunate. But better documentation should help. Robert Engels, you are right (as was Pelle) that UDP does not support OOB. But the oobbuffer and oobn are not (really, not kidding) about OOB. They are instead about what both the Linux and Microsoft documentation call the control buffer. That buffer is sometimes used to pass things along with the message for some protocols but I have not found a case where UDP uses that (still looking). It is also used to get additional information about the received message. The one case I have seen documented that I want to experiment with is when a machine has multiple interfaces and the UDP packet could have arrived on different ones. Then if you have set the right thing in the socket, you should get information about the interface in oobbuffer. And if oobbuffer is too short, MSG_CTRUNC should be set in the flags return. My short term goal is to see if I can get this working and then use what I find to suggest better documentation. -- 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.
