Greg,<div><br></div><div>Thanks a lot you for pointing out Coda project. I have a brief glance at it. Yep, Coda is a great project which doesn't a good job in server automatically replicate/rebalancing, and client caching. But, I like some features in Tahoe but not in Coda:</div>
<div><ol><li>Files saved encrypted in the server. This feature I like is because if I put the server in a hosting/cloud provider which I am not quite trust. Then, I protect my data in some level at least the provider needs gain root privilege to run the Tahoe code to access my data. Instead of simply reading the hard disk sector by sector.</li>
<li>The communication between servers are secured by transferring only encrypted data. I didn't find Coda supports that. It might be solved by just using SSL or IPSec tunnel for the RPC channel among Coda servers. But, I don't know if it is already implemented or if not, how easy to add this feature into Coda architect.</li>
<li>The communication between client and server, Tahoe supports all kinds of up-to-date protocols. I can force using HTTPS and SFTP if I really need secure channel. I didn't see Coda supports that.</li><li>File/Directory sharing between different clusters/grids. In Tahoe, this is just as easy as giving a filecap of the directory you want to share to others. In Coda, I don't know if the file system can be shared easily in any level of the file system. From my current understanding, the sharing and mounting point is happening on the volume level now.</li>
</ol>Certainly, I am still learning both projects to see what will be best fit for my deployment. What kind of trade-off I need to pay if I pick up one and if I need twist the code eventually to meet my goal.</div><div><br>
</div><div>For fixing the firewall, I don't quite understand you suggestion. Even through, I fixed my setup by opening a port in my firewall last time as you suggest if you remember. But, I don't think opening a port is eventually acceptable in my deployment. I prefer a zero firewall configuration effort as NAT traversal is so a popular technology already. I don't think Skype will get success if it has to ask everybody to twist their firewall ports at home. :-)</div>
<div><br></div><div>Thanks with regards,</div><div>-Shu</div><div><br><div class="gmail_quote">On Thu, Dec 2, 2010 at 5:18 AM, Greg Troxel <span dir="ltr"><<a href="mailto:gdt@ir.bbn.com">gdt@ir.bbn.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
For your use case tahoe is not yet baked enough.<br>
It's also possible tahoe is not the right tool for your problem.<br>
Also check out coda:<br>
  <a href="http://www.coda.cs.cmu.edu/" target="_blank">http://www.coda.cs.cmu.edu/</a><br>
<br>
tahoe doesn't currently have servers do resyncing automatically.  That's<br>
done by clients running repair.<br>
<br>
You might want to decouple the concept of client nodes and servers, even<br>
though by default a server is a client.<br>
<div class="im"><br>
  In my deployment, I would consider it is not acceptable that a1 can only be<br>
  accessed from A WUI because all my 3 servers are running in the different<br>
  places in the world behind their own firewalls. Accessing a file from remote<br>
  server from WUI is not acceptable and against the original security design<br>
  of Tahoe project.<br>
<br>
</div>Your clients all need to be able to connect to all servers.  You'll have<br>
to fix the firewall :-)<br>
<br>
share placement is not particularly well controlled, and in the tahoe<br>
vision is not super important - you have many servers and put shares on<br>
a number of them.<br>
<br>
I think you could change tahoe's code to do what you want; with 1/1/3<br>
sharing you can upload to 1 server (not having any redundancy) and then<br>
repair should try to copy to more servers as it is able.  While 1/1/3<br>
would be viewed as odd by most, 2/4/7 might be more normal and would<br>
still benefit from improved share placement and repair code.<br>
</blockquote></div><br></div>