Re: udp tunneling works but doesn't
Re: udp tunneling works but doesn't
- Subject: Re: udp tunneling works but doesn't
- From: email@hidden
- Date: Mon, 14 Nov 2005 12:41:51 -0700
On Nov 14, 2005, at 7:59 AM, Peter Sichel wrote:
I'm just catching up on the list and noticed there was no response
to your question below.
On 11/1/05, email@hidden wrote:
Now once I have my external IP and port, I try to
send a packet to myself like so:
192.168.0.5:10000 -> 4.3.2.1:54321 Hello
And I never get the packet! What gives?
As a NAT developer, I've seen this many times. Many NAT
implementations
do not provide "Local NAT" which allows hosts behind the NAT gateway
to access other private host using their public IP address. I've
implemented this feature in IPNetRouter, but it took some extra
work. Here's the typical NAT configuration:
Public Net --- NAT --- Gateway --- Private LAN
Ya, what I ended up doing was, reporting the local ip and port to
the main server, tunneling with the server to reveal the client's
global ip and port, and saving this info in a cache on the server.
Then I had each client read these addresses from the server and try
to send packets to the other clients until a reply was received. So
each would send a random, unique 128 bit cookie to local ip/local
port, a different cookie to global ip/global port, and another to
global ip/local port. The third case is how a lot of NATs allow
tunneling. Then if a cookie came back from the address/port, the
client knew that it was an available path to the other client, with
preference given to local, then global IPs.
This method works fine with the two routers I have tried, and lots
of combinations of wifi, modem, etc, but will fail for corporate
firewalls and places where all UDP is blocked. How often have people
here run across that case? Especially a case where clients have a
direct TCP route to the net so they can host, but UDP is blocked?
That is the case that would work with most existing games, so I feel
like I am leaving those people out by using only UDP. If UDP is
blocked, but the person also can't host with TCP, then they won't be
able to host without help from a public machine, period, and people
will probably already know that. And I am curious to know how many
people I am leaving out that would be able to at least play as
clients under TCP, but will not be able to play at all right now if
UDP is blocked. And how often does UDP appear blocked because a
router is busy and dropping packets to give preference to TCP? And
one more thing - has anyone tried sending out of band data over TCP,
and does this have low lag like UDP, and does it drop packets as well?
Anyway, if I do decide to fix it so that players behind firewalls
can host, one of the clients would have to be able to host with TCP,
and then act as a tunnel (proxy?) for the other clients, and if that
fails, I'd have to reserve some open ports on the main server. I am
not sure if I want to get into all of this. This is really getting
out of hand, and I imagine that is why there are so few p2p apps that
"just work" - mainly Skype, Limewire, BitTorrent, and Acquisition. I
don't consider very many other apps to be real p2p because they are
either agonizingly slow or simply don't "just work".
Anyway, this has been my experience, and I have spent the better
part of a decade researching this stuff and still learn some new
showstopper each day, so I can't really recommend this approach to
others. I am really looking forward to IPV6 someday, and I sure hope
they don't ruin it with son of NAT and firewall 2.0 which are just
bandaids IMHO :) Thanx for your help,
------------------------------------------------------------------------
Zack Morris Z Sculpt Entertainment This Space
email@hidden http://www.zsculpt.com For Rent
------------------------------------------------------------------------
If the doors of perception were cleansed, everything would appear to man
as it is, infinite. -William Blake, The Marriage of Heaven and Hell
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden