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

Examples? #6

Open
isaachess opened this issue Jun 20, 2017 · 4 comments
Open

Examples? #6

isaachess opened this issue Jun 20, 2017 · 4 comments

Comments

@isaachess
Copy link

I'm struggling to use this effectively and am wondering if you could provide some examples.

The actually communication with the STUN server works fine: it returns the public addr observed by the STUN server.

But USING this information isn't working for me, and it has me wondering if I'm just misunderstanding how the package works (thus the request for examples).

For example, when calling stun.Discover it returns a conn and addr. I'm attempting, after performing the discover, to receive UDP packets sent to addr. So I'm trying to read from the return conn (while sending UDP messages to addr from another machine), but nothing ever comes through.

The purpose of STUN in my understanding is to hole-punch so peers can send UDP traffic to the public addr, which is then forwarded to the correct host. Can I see an example of how this package gets that done?

@pixelbender
Copy link
Owner

@isaachess Yes, It should work exactly you described, but currently stun.Discover uses net.Dial instead of Listen (so, the socket is associated with a STUN-server's address) and hole-punching does not work. I'll fix it, thanks.

@kenkeiter
Copy link

I just spent the better part of a day tearing my hair out over this, so I wanted to make sure that I documented exactly what's happening here, in the hopes that someone else won't have to.

Although @pixelbender fixed the issue with the fact that net.Listen* wasn't being used, the net.PacketConn returned by Discover() isn't actually relinquished in a way that allows it to be repurposed! When the Conn is created, an Agent is set up to handle it. Upon start, the Agent calls this method, which calls ReadFrom on the net.PacketConn to loop over/handle received messages. Turns out, when the net.PacketConn is handed back to you from Discover(), that loop is never actually stopped.

I guess that's what @pixelbender meant by the TODO: hijack comment 😜 Anyway, long story short, it turns out that this issue hasn't really been addressed.

@kenkeiter
Copy link

@isaachess That PR (#8) should allow you to use this library for hole-punching. The net.PacketConn you get back is now usable, so if you know the public address (host/port) of your peer, you can get them to try to send packets to one another at the same time.

For what it's worth, you'll do something like this for both clients (although you still need an external service to help them exchange addresses):

conn, externalAddr, err := stun.Discover(STUNServer)
if err != nil {
	return nil, errors.Wrap(err, "failed to set up public UDP socket")
}
peerExternalAddr := &net.UDPAddr{
	IP: net.ParseIP("<peer addr>"),
	Port: 1234,
}
conn.WriteTo([]byte("hello"), peerExternalAddr)

@mennanov
Copy link

Could you please point me to the example on how to setup a TCP connection between 2 nodes both behind NAT?
Something like node1_code.go, node2_code.go, external_server_code.go
Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants