[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