[tahoe-dev] dynamic ip
Greg Troxel
gdt at ir.bbn.com
Sun Jun 16 12:17:23 UTC 2013
"erpo41 at gmail.com" <erpo41 at gmail.com> writes:
> If it helps, I've noticed that Tahoe seems to be designed for use in a
> business environment
I don't think that's true, although I agree with some of your points.
My comments are from my own usage that is heading towards a friendnet.
> where one entity controls all of the nodes
I this this is mostly not really true and not really important. There
are some issues which sort of relate, but they all feel independent.
> each node has a static IP
My experience has been that the introducer needs to have static address,
but that storage nodes and clients do not. Storage nodes do need to
have a globally-routable address, but that's different.
> there is very little down time
Agreed. This point (or its converses) is not really well integrated
into the current code. Repair has churn when nodes come and go.
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1209
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1210
> very little node turnover,
I'm not sure how much this matters, once the repair-churn issues are
fixed. But it's an interesting question. (One would need to define a
metric that relates filesystem behavior to node turnover.)
> very high internode bandwidth compared to gateway-user bandwidth,
I don't really follow this. In my view, the WUI/WAPI should be run on
computers needing access, and not accessed beyond a thought-secure LAN.
So I see user-gateway bandwidth as approaching memory speeds.
As for internode bandwidth, client nodes interact with storage nodes
(yes, I know some can be both). I don't see that tahoe makes any big
assumptions here. I also think that tahoe speed is typically not really
limited by bandwidth here as much as serializing round trips.
> There are some challenges in the "friends want to pool their extra storage"
> use case.
True. The biggest challenges I see are
accounting, so you can have some measure of fairness (even among
friends who are trying to be reasonable, you need a way to know if
you've accidentally consuemed 10x what you thought you had)
expiration/garbage-collection. There needs to be a way for old shares
to go away, but it needs to be safe against normal activities, and
safe against vanishing for a few months.
But I also think these challenges are not particularly about
allmydata.com vs friendnet - they apply to both. I believe both of
these are being worked on. With improvements for those two points and
fixes for ticket:1209 and ticket:1210, I think tahoe will be much more
usabl for the friendnet use case.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130616/1492580a/attachment.pgp>
More information about the tahoe-dev
mailing list