Nat punching

155 views
Skip to first unread message

Bicubic

unread,
May 9, 2010, 11:57:46 AM5/9/10
to lidgren-network
I've been trying to use SendNATIntroduction without much luck. I think
I understand where the problem is:
-master server runs a NetServer
-game host runs a NetClient which sends a register command which
consists of the host's server port to the master server. The master
server takes the associated NetConnection with that message and
remembers it.
game host also starts a NetServer for the actual game
-game client creates a NetClient and requests a host ip/port to
connect to from the master server
-master server sends host's ip and server port, begins nat
introduction between the host connection it remembers and the game
requester
-game client creates a new NetClient and begins connecting to the
received ip/port number
-punch does not succeed

The problem I see here is that the master server is actually
introducing two NetClients - that of the host and that of the client.
How do I introduce the client to the host's server?

Also, when should we expect to see this in gen3?

--
You received this message because you are subscribed to the Google Groups "lidgren-network" group.
To post to this group, send email to lidgren...@googlegroups.com.
To unsubscribe from this group, send email to lidgren-netwo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lidgren-network?hl=en.

lidgren

unread,
May 10, 2010, 3:36:27 AM5/10/10
to lidgren-network
Every time you bind to a socket you can expect to get a new external
port, so you need to use the same NetPeer (server/client) when sending
the message to the master server as you use for endpoint for the nat
punch thru. It goes something like this:

A sends a message to M and M records where that message came from (the
EXTERNAL endpoint that A cannot see itself)
B does the same.
M then sends the external endpoint of A to B and B to A and they start
sending packets to eachother.

I recommend using unconnected messages to communicate with a master
server.

I'll try get it into gen3 as soon as possible, with a sample to go.

--michael

Chris Cowherd

unread,
May 10, 2010, 11:39:26 AM5/10/10
to lidgren...@googlegroups.com
I'd like to add that M obviously knows the external endpoint as Michael pointed out but I also include A and B's LOCAL endpoint in the initial message they send to M.  This is because sometimes A and B are both on the same LAN (two people playing at home for instance) and they many times cannot reach each other over their external endpoints (I cannot on my network).  If A and B are on the same network they will make direct connections if the external connection attempts fail.

So I always do two NAT introductions each:

A => B's remote endpoint
A => B's local endpoint

B => A's remote endpoint
B => A's local endpoint


UDP Hole Punching, Peers Behind Different NATs:
img9.png


UDP Hole Punching, Peers Behind a Common NAT:
img8.png
img8.png
img9.png

lidgren

unread,
May 10, 2010, 11:53:25 AM5/10/10
to lidgren-network
That's a very good point; peers on the same network. Theoretically
they should be able to connect using external nat traversal; but these
things are magical to say the least so it's probably a good idea to
try both locally and externally.

I'm working on the NAT introduction for gen3 right now.

--michael


On 10 Maj, 17:39, Chris Cowherd <mad...@gmail.com> wrote:
> I'd like to add that M obviously knows the external endpoint as Michael
> pointed out but I also include A and B's LOCAL endpoint in the initial
> message they send to M.  This is because sometimes A and B are both on the
> same LAN (two people playing at home for instance) and they many times
> cannot reach each other over their external endpoints (I cannot on my
> network).  If A and B are on the same network they will make direct
> connections if the external connection attempts fail.
>
> So I always do two NAT introductions each:
>
> A => B's remote endpoint
> A => B's local endpoint
>
> B => A's remote endpoint
> B => A's local endpoint
>
> *UDP Hole Punching, Peers Behind Different NATs:*
> [image: img9.png]
>
> *UDP Hole Punching, Peers Behind a Common NAT:*
> > lidgren-netwo...@googlegroups.com<lidgren-network%2Bunsubscribe@ googlegroups.com>
> > .
> > > For more options, visit this group athttp://
> > groups.google.com/group/lidgren-network?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "lidgren-network" group.
> > To post to this group, send email to lidgren...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > lidgren-netwo...@googlegroups.com<lidgren-network%2Bunsubscribe@ googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/lidgren-network?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "lidgren-network" group.
> To post to this group, send email to lidgren...@googlegroups.com.
> To unsubscribe from this group, send email to lidgren-netwo...@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/lidgren-network?hl=en.
>
>  img8.png
> 46KVisaHämta
>
>  img9.png
> 53KVisaHämta
Reply all
Reply to author
Forward
0 new messages