I don't think this is the same thing. after I send out a too big UDP and receive the ICMP need fragment error, I can use MSG_ERRQUEUE flag to receive the mtu info from the same UDP socket. the icmp package only works when you send out a icmp package.
在 2017年7月15日星期六 UTC+8上午9:40:38，Matt Harden写道： > > Take a look at https://godoc.org/golang.org/x/net/icmp#PacketTooBig > > On Fri, Jul 14, 2017 at 6:01 AM <aman...@gmail.com <javascript:>> wrote: > >> I want to process the ICMP error and implement UDP PMTU discovery, so I >> have to call recvmsg with MSG_ERRQUEUE >> >> It has been 4 years, any reasonable solutions for this problem?? >> >> 在 2013年2月28日星期四 UTC+8下午9:31:54，Robert写道： >>> >>> +cc golang-dev >>> +bcc golang-nuts >>> >>> Hello, >>> >>> I would like to propose a change in the net package in the >>> {Read,Write}Msg* methods (they are to be new in Go1.1), so that they >>> allow flags to be passed in. As far as I know, the only way to read a >>> socket's error queue in Linux is to use recvmsg with MSG_ERRQUEUE flag >>> set. The {Read,Write}Msg methods don't allow flags to be passed in and >>> set them always to 0. >>> >>> I propose that both ReadMsg* and WriteMsg* take an additional argument >>> for flags. This obviously exports system-specific flags out of the net >>> package, but we already do that in the other direction in these same >>> methods. ReadMsg should filter out MSG_WAITALL (because it seems >>> nonsensical or poorly defined for nonblocking operations); all other >>> flags from POSIX and Linux-specific ones seem not to interfere with >>> the assumptions related to the poll server or nonblocking behaviour. I >>> also propose that ReadMsgUnix set MSG_CMSG_CLOEXEC, for similar >>> reasons we set O_CLOEXEC in open() (although I'm not sure if that >>> shouldn't be the domain of someone who actually uses SCM_RIGHTS). For >>> WriteMsg* I didn't find any flags that would seem to interfere with >>> assumptions related to the poll server and nonblocking behaviour. >>> >>> I will send a CL upon request; I didn't do it first because the >>> contributing guidelines strongly advise against that. This is a change >>> that, as far as I understand the backwards compatibility guarantees, >>> should be made before Go1.1 or not at all in the foreseeable future. >>> >>> Robert >>> >>> On Thu, Feb 28, 2013 at 2:58 AM, Mikio Hara <mikioh...@gmail.com> >>> wrote: >>> >> Would adding a way to call ReadMsg with flags be reasonable? >>> > >>> > And WriteMsg too? Not sure, but Read/WriteMsgIP, UDP methods >>> > are new API for Go 1.1. I think you can contribute a bugfix patch >>> > until Go 1.1 cutoff if you think that's an API design bug. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-dev+...@googlegroups.com <javascript:>. >> For more options, visit 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.
