Jody Harris wrote: > > That may be a real stumbling block for my "big plans." I was hoping to > use tahoe-lafs as a apotheca populi (storage for the people). If "the > people" is defined as "average internet home user," then there is no > way to achieve this unless the introducer can act as a "tunnel" for > the whole grid/cloud.
We've talked about this off and on.. the core issue is making it possible for NAT-bound home users to provide storage space, and that requires some kind of data path from an arbitrary client (also NAT-bound) to all the storage servers. (incidentally, I don't think this sort of "tunnel" functionality should be an Introducer responsibility.. I'd like to restrict the Introducer's job to telling everybody about everybody else, and give some other component the job of helping everybody actually exchange data with everybody else). This gets you into the realm of STUN and STUNT and various hole-punching techniques (tickets #50 and #169). It's also in the UPnP space (ticket #49). The P2P community has been working on it for years, with varying results. Skype is great at this, but their techniques are proprietary and secret. In general, if you have some sort of coordination node (possibly centralized, possibly running on any "supernode" that appears to have a public IP), you can coerce two NAT-bound hosts to establish a direct TCP connection to each other, but it's a hassle. UDP is marginally easier, but then you have to build a suitable protocol on top of UDP, whereas TCP is just so darn convenient. It's easier to build public-IP relay servers (ticket #445), but relatively expensive to run them, since all the data has to go through the relay. In that scenario, someone who wants to offer storage space (but who does not have a public IP) must talk someone (who does) into spending bandwidth on their behalf. Then they publish the relay's connection information. In Tahoe+Foolscap terms, they'd publish a FURL that has a connection hint which points at the relay, and maintain an outbound connection to the relay, along which the data of inbound connections could be forwarded. We've put more thought into this one than into anything else, see also foolscap#46. You could also imagine a sort of store-and-forward system, in which you upload your shares to a publically-visible holding bin, and then later the "real" (but NAT-bound) server connects to that bin and pulls down the shares they're supposed to hold. When a client wants to download the share, they ask the bin, which tells the server, which *uploads* the share into the bin, then the client can download it from the bin. This would be a lot like the #445 relay idea, but slightly more asynchronous (the bin-to-server transfer could happen leisurely, when the bandwidth was available). I agree that this would be a great feature to have. We haven't built it into Tahoe yet because it's kinda hard. Building a basic relay would be a good first step that would provide significant functionality.. that's where I'd start. cheers, -Brian ticket URLs: http://allmydata.org/trac/tahoe/ticket/49 http://allmydata.org/trac/tahoe/ticket/50 http://allmydata.org/trac/tahoe/ticket/169 http://allmydata.org/trac/tahoe/ticket/445 http://foolscap.lothar.com/trac/ticket/46 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
