Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: UDPConn.LocalAddr() of ListenUDP returns "0.0.0.0:11110" instead of "127.0.0.1:11110" or "10.16.83.185:11110" #26347

Closed
woniuxu opened this issue Jul 12, 2018 · 5 comments

Comments

@woniuxu
Copy link

woniuxu commented Jul 12, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.9.2 linux/amd64

What did you do?

Server side:

ServerAddr,err := net.ResolveUDPAddr("udp",":11110")
ServerConn, err := net.ListenUDP("udp", ServerAddr)
n,addr,err := ServerConn.ReadFromUDP(buf)
fmt.Println("Received ",string(buf[0:n]), " from ",addr, " to ", ServerConn.LocalAddr())

Client side:

ServerAddr1,err := net.ResolveUDPAddr("udp", "10.16.83.185:11110")
Conn1, err := net.DialUDP("udp", nil, ServerAddr1)
_,err := Conn1.Write(buf)

ServerAddr2,err := net.ResolveUDPAddr("udp", "127.0.0.1:11110")
Conn2, err := net.DialUDP("udp", nil, ServerAddr2)
_,err := Conn2.Write(buf)

What did you expect to see?

Received  1  from  10.16.83.185:51386  to  10.16.83.185:11110
Received  1  from  127.0.0.1:58306  to  127.0.0.1:11110

What did you see instead?

Received  1  from  10.16.83.185:51386  to  0.0.0.0:11110
Received  1  from  127.0.0.1:58306  to  0.0.0.0:11110

So what shoud i do to get the "expect" result? Thanks.

@woniuxu woniuxu changed the title net:UDPConn.LocalAddr() of ListenUDP returns "0.0.0.0:11110" instead of "127.0.0.1:58306" or "10.16.83.185:51386" net:UDPConn.LocalAddr() of ListenUDP returns "0.0.0.0:11110" instead of "127.0.0.1:11110" or "10.16.83.185:11110" Jul 12, 2018
@ianlancetaylor ianlancetaylor changed the title net:UDPConn.LocalAddr() of ListenUDP returns "0.0.0.0:11110" instead of "127.0.0.1:11110" or "10.16.83.185:11110" net: UDPConn.LocalAddr() of ListenUDP returns "0.0.0.0:11110" instead of "127.0.0.1:11110" or "10.16.83.185:11110" Jul 12, 2018
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 12, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Jul 12, 2018
@ianlancetaylor
Copy link
Contributor

cc @mikioh

@mikioh mikioh removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 12, 2018
@mikioh mikioh modified the milestones: Go1.12, Unreleased Jul 12, 2018
@mikioh
Copy link
Contributor

mikioh commented Jul 12, 2018

@woniuxu,

The LocalAddr method of UDPConn returns an address requested to the protocol stack inside the kernel that represents what traffic you want to receive. It's part of the convention how to represent an identifier that allows us to receive traffic on all available unicast and anycast IP addresses of the local system, and not Go standard library-specific (well, I guess it was born at and came from Berkeley.) The net package documentation tries to describe the convention a bit; please take a look at https://godoc.org/net#ListenUDP and https://godoc.org/net#ListenPacket.

If you think we can do more better on the documentation, feel free to open a new issue for documentation improvement. In general, network-layer identifiers must be opaque to application-layer users. I'm still not sure the reason why application-layer people want to know the hidden structure on the identifiers without knowing the architecture and design limitations on functional planes that need the identifiers.

@mikioh mikioh closed this as completed Jul 12, 2018
@woniuxu
Copy link
Author

woniuxu commented Jul 13, 2018

@mikioh

"The LocalAddr method of UDPConn returns an address requested to the protocol stack inside the kernel that represents what traffic you want to receive."

That makes sense for LocalAddr method of UDPConn.

" It's part of the convention how to represent an identifier that allows us to receive traffic on all available unicast and anycast IP addresses of the local system, and not Go standard library-specific (well, I guess it was born at and came from Berkeley.) The net package documentation tries to describe the convention a bit; please take a look at https://godoc.org/net#ListenUDP and https://godoc.org/net#ListenPacket."

Yes, it's a convention to use "0.0.0.0:port" or ":port" format for receiving traffic on all available ip address. But with C++, though bind m_iSock with address like ":port" or "0.0.0.0:port", I can get the server's "real" localAddr which is the client's remote address by "::getsockname(m_iSock, addr, &addr_len)".

So, regardless of UDPConn. How can i get the server's "real" localAddr while i want to recevie udp traffic on all available unicast and anycast IP addresses of the local system with golang? Thanks.

@mikioh
Copy link
Contributor

mikioh commented Jul 13, 2018

@woniuxu,

Please use other forums: https://github.com/golang/go/wiki/Questions.

In general, if your running kernels or libraries in other languages provide something useful for you, it's easy to recreate in your own packages. I can guess that the word "real" you are saying means that something per-packet information because you are using "connection-less or stateless" datagram-based transport protocols such as UDP. Well, it's better to ask your question in more appropriate forums.

@woniuxu
Copy link
Author

woniuxu commented Jul 13, 2018

@mikioh

Yes, in the example i mentioned, "real" address means :
"Received 1 from 10.16.83.185:51386 to 10.16.83.185:11110
Received 1 from 127.0.0.1:58306 to 127.0.0.1:11110".
Not
"Received 1 from 10.16.83.185:51386 to 0.0.0.0:11110
Received 1 from 127.0.0.1:58306 to 0.0.0.0:11110"

I'll refer to the forums for some guides. Thank you.

@golang golang locked and limited conversation to collaborators Jul 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants