[tahoe-dev] Tahoe-lafs and nodes behind NAT (behind another NAT)

[Nathan Eisenberg]

I do like the idea of using IPv6 brokerage to avoid the problem altogether.  I don't know how much work has been put into tahoe from an ipv6 perspective, if it 'just works', or if no one knows, but it seems like it would be the most future-proof way of combating the problem, since any grid utilizing it can just be rolled forward into native IPv6 transport when it becomes available for each node.

Best Regards,
Nathan Eisenberg
Sr. Systems Administrator - Atlas Networks, LLC
office: 206.577.3078 | suncadia: 206.210.5450
www.atlasnetworks.us | www.suncadianet.com

From: tahoe-dev-bounces at allmydata.org [mailto:tahoe-dev-bounces at allmydata.org] On Behalf Of Jody Harris
Sent: Sunday, December 20, 2009 7:54 AM
To: tahoe-dev at allmydata.org
Subject: Re: [tahoe-dev] Tahoe-lafs and nodes behind NAT (behind another NAT)

BitTorrent is another open project that has overcome these kinds of problems.

Don't take this personally, I'm just brainstorming, and this thread is the best place to do that.

So, running list of technologies that have overcome this problem:
 - SIP
 - IM file transfer
 - BitTorrent

There's an article at The H about "How Skype & Co. Get Round Firewalls."
http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.html

It's on my reading list for this week.

I'm fully aware of the blood and gore involved in ripping out a piece of code like this and replacing it. It's going to be ugly. I'm just looking around for existing solutions. Brilliance does not reside in "original solutions," but rather in employing "the wheel" in unexpected ways. Often, the best way to solve a difficult problem is not to pop open the hood and get elbow-deep in [code] yourself, but rather it is pointing the right person at the solution and letting them surprise you.

j
----
- Think carefully.
- Contra mundum - "Against the world" (St. Athanasius)
- Credo ut intelliga - "I believe that I may know" (St. Augustin of Hippo)

On Sat, Dec 19, 2009 at 3:25 PM, Zooko Wilcox-O'Hearn <zooko at zooko.com<mailto:zooko at zooko.com>> wrote:
There are currently five tickets about making it easier for people to
use Tahoe-LAFS through firewalls and NATs.  You can see them by gong
to the ViewTickets page:

http://allmydata.org/trac/tahoe/wiki/ViewTickets

and scrolling down to the "Keywords" section and look for the keyword
"firewall".  They are these:

http://allmydata.org/trac/tahoe/ticket/49#<http://allmydata.org/trac/tahoe/ticket/49> UPnP
http://allmydata.org/trac/tahoe/ticket/50#<http://allmydata.org/trac/tahoe/ticket/50> STUNT/ICE
http://allmydata.org/trac/tahoe/ticket/169#<http://allmydata.org/trac/tahoe/ticket/169> tcp hole-punching!
http://allmydata.org/trac/tahoe/ticket/445#<http://allmydata.org/trac/tahoe/ticket/445> implement relay: allow
storage servers behind NAT
http://allmydata.org/trac/tahoe/ticket/754#<http://allmydata.org/trac/tahoe/ticket/754> merge manually specified
tub location with autodetected tub location

There are some interesting things in some of these!  In #49 Shawn
Willden did a quick experiment (sort of what Extreme Programming
calls a "spike") with miniupnp that was promising.  In #169 Greg
Hazel offered some Python code to integrate TCP hole-punching magic
right into the Python sockets.

My personal favorite approach right now is the extend the helper to
do immutable download, mutable upload, and mutable download and then
treat the helper as the preferred solution for this problem.
However, like Shawn, I am not volunteering to work on this right
now.  (If you want to know what I'm volunteering to work on right now
search for tickets that I've accepted.  I'm mostly trying to finish
#778 and other tickets that I consider essential for v1.6, plus fix
up buildbots and other testing or quality control issues that I
consider essential for v1.6.)

Regards,

Zooko
_______________________________________________
tahoe-dev mailing list
tahoe-dev at allmydata.org<mailto:tahoe-dev at allmydata.org>
http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20091220/976ab75c/attachment.html>