While reading planet gnome, I saw an interesting article about peer to peer communication behind NATs. As I believe it's what's being used for games and applications such as Skype. The technique is easy but comes with a drastic drawback - it works only for UDP (as far as I know). I know that I need not to tell anybody here about the wonderful features of TCP, but as I see it, most of these features can be mimicked on UDP. It all comes down to agreeing upon a strategy and policy for how to guarantee the arrival, uniqueness, and order of the packets. This should not require very many hours, and the use of hashes as we are familiar with now, might be helpful. For those who don't know how p2p between two NAT:ed hosts works, here's an extract from the NAT RFC: /NATs should not change the number of UDP ports used by a stream of packets./ And the idea is: Let's say we have two NAT:ed peers, "P1" and "P2", and an ADC hub "H". P1 wants to connect to P2, and sends a UDP packet to P2. This packet will be "dropped" at P2's NAT, but P1's NAT now automatically accepts incoming UDP packets from P2 from now on. P1 also sends a (adc-tcp) request to the hub, which tells P2 to send a UDP packet back to P1, the same way P1 did. Now P2's NAT accept UDP packets from P1, and this latter packet sent by P2 to P1 will be received. From now on, the UDP packets sent between P1 and P2 will be received, as long as their NAT's don't mess around too much (this is not a _completely_ safe method, but is being widely used by many protocols if I've understood it correctly). Connections between two NAT:ed peers is a requirement for a protocol like ADC to not be obsolete upon its release, since this is the way to go, for today's protocols. What this will require from us is a layer above the UDP which gives us what TCP already has given us, as well as a new protocol message (besides CTM and RCM). I just wanted to raise this as a topic, wondering if anyone else is interested in it. I simply like the idea of anyone being able to connect to anyone else. Opera --
On Friday 11 February 2005 14:27, Gustaf Räntilä wrote:
> And the idea is: > Let's say we have two NAT:ed peers, "P1" and "P2", and an ADC hub "H". > P1 wants to connect to P2, and sends a UDP packet to P2. This packet will > be "dropped" at P2's NAT, but P1's NAT now automatically accepts incoming > UDP packets from P2 from now on. P1 also sends a (adc-tcp) request to the > hub, which tells P2 to send a UDP packet back to P1, the same way P1 did. > Now P2's NAT accept UDP packets from P1, and this latter packet sent by P2 > to P1 will be received. From now on, the UDP packets sent between P1 and P2 > will be received, as long as their NAT's don't mess around too much (this > is not a _completely_ safe method, but is being widely used by many > protocols if I've understood it correctly).
Yes, this sounds logical, but many NAT routers will rewrite the source port, and the scheme you outlined relies on the fact that the parts are sending to the correct ports which will be opened for a brief window of time (45 seconds is default in Linux at least). In the cases where the source port have been changed by the router, the clients have no way of knowing which port to send to, thus communication cannot be established. I suspect this happens more frequently on routers when there is high amounts of traffic going on.
> Connections between two NAT:ed peers is a requirement for a protocol like > ADC to not be obsolete upon its release, since this is the way to go, for > today's protocols. What this will require from us is a layer above the UDP > which gives us what TCP already has given us, as well as a new protocol > message (besides CTM and RCM).
CTM have a command parameter for this exact reason. The thing we need is a standardized CTCP for control channel via hub, and an additional protocol for such udp traffic. That can be done by merely adding a few commands to the hub, so the hub doesn't need to be updated much at all.
> I just wanted to raise this as a topic, wondering if anyone else is > interested in it. I simply like the idea of anyone being able to connect to > anyone else.
And an interesting one ;)
> Opera
hm, are you my employer ? :) Cheers janvidar / Dj Offset -- Jan Vidar Krey E-mail: janvidar@extatic.org Mobile: +47 98607328 WWW : http://www.extatic.org/ --
On Friday 11 February 2005 14:27, Gustaf Räntilä wrote:<... Snip UDP port-punching scheme ...>
Yes, this sounds logical, but many NAT routers will rewrite the source port, and the scheme you outlined relies on the fact that the parts are sending to the correct ports which will be opened for a brief window of time (45 seconds is default in Linux at least). In the cases where the source port have been changed by the router, the clients have no way of knowing which port to send to, thus communication cannot be established.
I suspect this happens more frequently on routers when there is high amounts of traffic going on.
CTM have a command parameter for this exact reason. The thing we need is
a standardized CTCP for control channel via hub, and an additional protocol for such udp traffic. That can be done by merely adding a few commands to the
hub, so the hub doesn't need to be updated much at all.
> -----Original Message----- > From: dcdev-bounces@dcportal.net [mailto:dcdev-bounces@dcportal.net] On > Behalf Of blackclaw@parsoma.net > Sent: Friday, February 11, 2005 4:09 PM > To: Direct Connect developers > Subject: Re: [dcdev] ADC already obsolete? > > Evidently it works fairly frequently; see > http://zgp.org/pipermail/p2p-hackers/2004-November/002171.html and the > paper it references. This seems work persuing. For others, there's still > passive mode.
Interesting if TCP 'hole punching' works as frequently as they claim, anyway to increase the probability of it working one can: 1) Try TCP hole punching (TCP is always very nice) 2) Try UDP hole punching if TCP didn't work 3) Send the initial UDP-packet to both the other peer and the hub, so that the hub sees the source address, and thereby forward it to the peer(s), and hope that the NAT at least keep the source port, even if it's not the same as the senders local port (which really doesn't matter then).
> > CTM have a command parameter for this exact reason. The thing we need is > > a standardized CTCP for control channel via hub, and an additional> protocol> > for such udp traffic. That can be done by merely adding a few commands> to the> > hub, so the hub doesn't need to be updated much at all.> > It directly concerns the difference between command types A and B; > that's fairly fundamental. Further, INF's U[46] parameters are involved. > One might wish to more tightly integrate this into ADC than a few > CTCP-lookalike-commands.
If my third try works, it definitely requires something new from the hub.
> DC++ also now supports UPnP, which obviates this in a friendly NAT > environment.
Yeah, I made a 5 minute try to incorporate UPnP to my linux netfilter NAT, and I had no luck. I'm not gonna try again ever until it gets natively into netfilter. Until then, manual configuration will do just... hrmpf... 'fine'. Opera --
> -----Original Message----- > From: dcdev-bounces@dcportal.net [mailto:dcdev-bounces@dcportal.net] On > Behalf Of Jan Vidar Krey > Sent: Friday, February 11, 2005 3:28 PM > To: Direct Connect developers > Subject: Re: [dcdev] ADC already obsolete? > > Yes, this sounds logical, but many NAT routers will rewrite the source > port, > and the scheme you outlined relies on the fact that the parts are sending > to > the correct ports which will be opened for a brief window of time (45 > seconds > is default in Linux at least). In the cases where the source port have > been > changed by the router, the clients have no way of knowing which port to > send > to, thus communication cannot be established. > > I suspect this happens more frequently on routers when there is high > amounts > of traffic going on.
Well the question is whether they (the NAT's) close the window after 45 seconds from the first packet, or the 'last' packet, since a timeout of a silent p2p channel can be 5 seconds with no problem, just go again if needed. I think the timeout is even smaller in DC today.
> > Opera> > hm, are you my employer ? :)
Hmm, not that I am aware of? =) Opera --
> > I suspect this happens more frequently on routers when there is high > > amounts > > of traffic going on.> > Well the question is whether they (the NAT's) close the window after 45 > seconds from the first packet, or the 'last' packet, since a timeout of a > silent p2p channel can be 5 seconds with no problem, just go again if > needed. I think the timeout is even smaller in DC today.
The Linux behaveour, that makes sense to me, is that the connection is closed by the connection tracker after 45 seconds idle, which means the timer is reset for every packet traversing. So if you don't get an answer within 45 seconds, you will not get it, most likely.
> > > Opera> > hm, are you my employer ? :)> Hmm, not that I am aware of? =)
Heh, had to ask, just started last week :) -janvidar- Men have as exaggerated an idea of their rights as women have of their wrongs. -- E.W. Howe --
> -----Original Message----- > From: dcdev-bounces@dcportal.net [mailto:dcdev-bounces@dcportal.net] On > Behalf Of Jan Vidar Krey > Sent: Friday, February 11, 2005 5:40 PM > To: Direct Connect developers > Subject: Re: [dcdev] ADC already obsolete? > > The Linux behaveour, that makes sense to me, is that the connection is > closed by the connection tracker after 45 seconds idle, which means the > timer is reset for every packet traversing. So if you don't get an answer > within 45 seconds, you will not get it, most likely.
Which to me is a perfectly acceptable behaviour. It's just like any other connection then, you'll have to initiate another connection after a certain timeout. And about the statistics, it's very much not scientific, but gives a good hint about the probability of this hacks success. NetGear and D-Link being the absolutely most widely used routers for poor DC-geeks works very well it seems. And Windows being the most used OS especially among DC users works to 100%. This on UDP. So I'd like to say that at least 85-90% of the current passive users would support this punching, but since it takes two to tango - the percentage must be squared, so about 70-80% success in the end. Good enough for me. But this definitely needs testing before I can open up the champagne ;) My reference being the article col pointed to - http://www.brynosaurus.com/pub/os/nat.pdf Opera --
On Fri, 11 Feb 2005 18:10:26 +0100, Gustaf Räntilä <opera@home.se> wrote:
> So I'd like to say that at least 85-90% of the current passive users would support this punching
Ironically enough, this is nearly the same as my (completely unsupported) estimate of the number of users behind a router who are too lazy or technically ignorant to set up port forwarding or UPnP properly. This concern for the end-users seems completely unlike the Opera from a year ago. Congratulations. -- Todd Pederzani todd.pederzani@gmail.com --