Eventmachine talk - Nov 2007 - P2P: Avoiding manual port-forwarding (am I

Howdy folks,

I''m writing a P2P app that needs both TCP and UDP characteristics.
(UDP for unreliable realtime data where it makes no sense to
retransmit lost packets; TCP for reliable and/or high-bandwidth
transfers.)

The sticking point is I want the app to just ''work'' out of the
box for N-way p2p connections, without needing to instruct the
user to forward port such-and-such on their router, to enable
their system to accept incoming connections.

The good news is, from my testing so far, it seems that once the
peers have determined each other''s mutual IP''s and ports
(which
will happen via a centralized server) then the peers can start
talking to one another over UDP even though they may each be
behind NAT firewalls.  (I expected this to work, and it has so
far in all cases except [1].)

However, I can''t think of any way to make this trick work with
TCP.

So my current crazy idea is just to punt and do all communication
over UDP.  But I want reliable high bandwidth TCP-like streaming
as well, so...  I''m thinking of extracting the TCP code from this
light weight IP stack [2] and tunneling TCP on my UDP packets.
(Note: This is just for my P2P communication.  If I want to talk
with a regular TCP server, I''ll use regular TCP.)

Anyway, I guess what I''m wondering is - does this sound crazy?
<grin>

I mean I''d love to hear something like, wow, why go through all
that trouble, when you can just XYZ and get regular TCP working
for peers behind NAT firewalls!

Because this TCP-over-UDP tunneling is the only solution I''ve
been able to think of so far.

Any thoughts?

Thanks!

Bill

[1] The auto-NAT UDP trick will fail if an overzealous router
at the destination decides to bounce a packet back with "udp port
NNNNN unreachable for IP".  In which case the originating peer''s
router receiving the bounced packet will tend to close it''s
temporary port forwarding.  But this seems to be rare.

[2] http://savannah.nongnu.org/projects/lwip/

stunt does this.
You could do it, for sure.  Just create your own headers and the like.
-Roger

On Nov 19, 2007 10:12 PM, Bill Kelly <billk at cts.com>
wrote:
>
> Howdy folks,
>
> I''m writing a P2P app that needs both TCP and UDP characteristics.
> (UDP for unreliable realtime data where it makes no sense to
> retransmit lost packets; TCP for reliable and/or high-bandwidth
> transfers.)
>
> The sticking point is I want the app to just ''work'' out
of the
> box for N-way p2p connections, without needing to instruct the
> user to forward port such-and-such on their router, to enable
> their system to accept incoming connections.
>
> The good news is, from my testing so far, it seems that once the
> peers have determined each other''s mutual IP''s and ports
(which
> will happen via a centralized server) then the peers can start
> talking to one another over UDP even though they may each be
> behind NAT firewalls.  (I expected this to work, and it has so
> far in all cases except [1].)
>
> However, I can''t think of any way to make this trick work with
> TCP.
>
> So my current crazy idea is just to punt and do all communication
> over UDP.  But I want reliable high bandwidth TCP-like streaming
> as well, so...  I''m thinking of extracting the TCP code from this
> light weight IP stack [2] and tunneling TCP on my UDP packets.
> (Note: This is just for my P2P communication.  If I want to talk
> with a regular TCP server, I''ll use regular TCP.)
>
> Anyway, I guess what I''m wondering is - does this sound crazy?
> <grin>
>
> I mean I''d love to hear something like, wow, why go through all
> that trouble, when you can just XYZ and get regular TCP working
> for peers behind NAT firewalls!
>
> Because this TCP-over-UDP tunneling is the only solution I''ve
> been able to think of so far.
>
> Any thoughts?
>
> Thanks!
>
> Bill
>
> [1] The auto-NAT UDP trick will fail if an overzealous router
> at the destination decides to bounce a packet back with "udp port
> NNNNN unreachable for IP".  In which case the originating
peer''s
> router receiving the bounced packet will tend to close it''s
> temporary port forwarding.  But this seems to be rare.
>
> [2] http://savannah.nongnu.org/projects/lwip/
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>


--
-Roger Pack
For God hath not given us the spirit of fear; but of power, and of
love, and of a sound mind" -- 2 Timothy 1:7

On Nov 20, 2007 12:12 AM, Bill Kelly <billk at cts.com>
wrote:
>
> Howdy folks,
>
> I''m writing a P2P app that needs both TCP and UDP characteristics.
> (UDP for unreliable realtime data where it makes no sense to
> retransmit lost packets; TCP for reliable and/or high-bandwidth
> transfers.)
>
> The sticking point is I want the app to just ''work'' out
of the
> box for N-way p2p connections, without needing to instruct the
> user to forward port such-and-such on their router, to enable
> their system to accept incoming connections.

I''m amazed that this works under UDP, much less TCP. Are we talking
about arbitrary UDP ports just getting forwarded through NATting
routers, without needing to set up firewall rules? Do you have any
references on this technique?

Yes, have a look at ICE / STUN

ICE is the IETF standard encompassing STUN

You''re out of luck with TCP, unless you use uPnP

On Nov 19, 2007 11:43 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:
> stunt does this.
> You could do it, for sure.  Just create your own headers and the like.
> -Roger
>
> On Nov 19, 2007 10:12 PM, Bill Kelly <billk at cts.com> wrote:
> >
> > Howdy folks,
> >
> > I''m writing a P2P app that needs both TCP and UDP
characteristics.
> > (UDP for unreliable realtime data where it makes no sense to
> > retransmit lost packets; TCP for reliable and/or high-bandwidth
> > transfers.)
> >
> > The sticking point is I want the app to just ''work''
out of the
> > box for N-way p2p connections, without needing to instruct the
> > user to forward port such-and-such on their router, to enable
> > their system to accept incoming connections.
> >
> > The good news is, from my testing so far, it seems that once the
> > peers have determined each other''s mutual IP''s and
ports (which
> > will happen via a centralized server) then the peers can start
> > talking to one another over UDP even though they may each be
> > behind NAT firewalls.  (I expected this to work, and it has so
> > far in all cases except [1].)
> >
> > However, I can''t think of any way to make this trick work
with
> > TCP.
> >
> > So my current crazy idea is just to punt and do all communication
> > over UDP.  But I want reliable high bandwidth TCP-like streaming
> > as well, so...  I''m thinking of extracting the TCP code from
this
> > light weight IP stack [2] and tunneling TCP on my UDP packets.
> > (Note: This is just for my P2P communication.  If I want to talk
> > with a regular TCP server, I''ll use regular TCP.)
> >
> > Anyway, I guess what I''m wondering is - does this sound
crazy?
> > <grin>
> >
> > I mean I''d love to hear something like, wow, why go through
all
> > that trouble, when you can just XYZ and get regular TCP working
> > for peers behind NAT firewalls!
> >
> > Because this TCP-over-UDP tunneling is the only solution I''ve
> > been able to think of so far.
> >
> > Any thoughts?
> >
> > Thanks!
> >
> > Bill
> >
> > [1] The auto-NAT UDP trick will fail if an overzealous router
> > at the destination decides to bounce a packet back with "udp port
> > NNNNN unreachable for IP".  In which case the originating
peer''s
> > router receiving the bounced packet will tend to close it''s
> > temporary port forwarding.  But this seems to be rare.
> >
> > [2] http://savannah.nongnu.org/projects/lwip/
> >
> >
> > _______________________________________________
> > Eventmachine-talk mailing list
> > Eventmachine-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/eventmachine-talk
> >
>
>
>
> --
> -Roger Pack
> For God hath not given us the spirit of fear; but of power, and of
> love, and of a sound mind" -- 2 Timothy 1:7
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071120/041a52e9/attachment.html