algorithm - 集中/分布式共享

Question

我想做一个系统，用户可以上传和下载文件。系统将具有一个集中的地形，但在很大程度上依赖于节点将相关数据通过中心节点传输给其他节点我不希望对等端保存整个文件，而是希望它们保存整个数据集的一个压缩的加密部分。
一些客户端匿名上传文件到服务器
我希望客户端能够使用某种NAT（随机IP）上传，意识到服务器将无法将确认数据包发送回客户端。确保数据完整性是可行的吗？头部中继总内容长度，如果存在不匹配，则忽略整个上载？
服务器对数据进行索引、压缩和拆分，将数据分成块，为每个块添加标识字节，对其进行加密，并在映射每个块的位置时通过网络拆分数据。
服务器还将根据请求更新对等方的文件索引。随着更多的数据被添加到系统中，我认为压缩可以变得更加高效。我希望能够将这些新的字典条目推送到对等方，这样他们就可以更新自己的块和客户端软件中的解压缩系统，而不会造成明显的网络压力。如果加密，块可以很大，而任何客户端都不知道有一部分x文件。
一些客户端请求文件
中心节点执行查找以确定块在网络中的位置，并从对等节点请求这些块一旦这些块组装好，它们就被发送（仍然是加密和压缩的）到客户端，然后客户端将内容转换成解压缩的文件。如果一个加密的请求可以通过一个对等方发出并转发到一个服务器，而洋葱则可以通过多个路径进行端到端的加密，那就太好了。
在后台，服务器将监视块的稳定性和冗余性，如果有必要，将承担几乎灭绝的块，如果有愿意的客户，可以将它们保存在自己的银行中，或者通过网络重新分配这样，中心节点可以根据需要收缩和增长。
我们的目标是建立一个网络，在这个网络中，任何客户端都可以上传或下载数据，而没有任何一个其他的对等方知道谁也做过，但可以免费和开放地访问所有人。
系统必须能够处理大量的同时连接，同时管理对等点和数据库，而不会失去它的头。
你的最佳实施方案是什么？
编辑：悬赏开启。
上周末，我实现了一个系统，基本上完成了上面的工作，减去第1部分。对于上传，我只是实现了SSL而不是伪造IP地址这个体系在几个方面很薄弱。文件被分成1MB块并加密，然后随机发送给注册的对等方。每个区块的收件人都存储在数据库中我担心这会很快变得太大，无法管理，但我也希望避免大量的块请求涌入网络。当请求一个文件时，中心节点通知拥有块的节点，它们需要将块发送到x客户端（在p2p模式下）或服务器（在直接模式下），然后服务器向下传输文件。这个系统只是一个大黑客，而且是用ruby编写的，我想它并不能真正胜任这个任务。对于重写，我考虑使用C++与Boost.Asio。
我正在寻找有关架构和系统设计的一般建议我一点也不喜欢我现在的实现。
当前地形
服务器处理客户端上传、索引和内容传播
处理客户端请求的服务器
用于上载文件和请求文件的客户端
客户端服务器接受块和请求
我希望客户端不必运行持久服务器，但我想不出一个好办法来解决这个问题。
我会张贴一些代码，但它令人难堪。谢谢。请提出任何问题，基本思想是有一个像样的匿名文件共享模型，结合了分布式和集中式的内容分发模型的优点。如果你有一个完全不同的想法，请随时张贴，如果你想。

Answer 1

我希望客户能够
使用某种NAT上传
（随机IP），实现服务器
无法发送确认
数据包返回到客户端是
确保数据完整性
转送全部内容的标题
长度，忽略整个
是否存在不匹配项？
不，那不可行如果您的数据包是1500字节，并且您的数据包丢失率为0.1%，则在不丢失任何数据包的情况下上载1兆字节文件的可能性为.999^（1048576/1500）=0.497，或低于50%。此外，还不清楚如果服务器无法向客户端发送确认，客户端如何知道上载是否成功。
解决确认问题的一种方法是使用rateless code，它允许客户机计算并发送有效的无限个唯一块，以便任何足够大的子集都足以重建原始文件。然而，这对客户端和服务器都增加了大量的复杂性，并且仍然需要某种方式通知客户端服务器已经接收到完整的文件。
在我看来你混淆了几个问题。如果您的系统有一个集中式组件供您的客户端上载，那么您为什么需要进行NAT遍历呢？
对于问题的第二部分和第三部分，您可能需要研究Distributed Hash Tables和基于内容的寻址（但要解释主要的注意事项）。防止节点知道它们存储的文件的内容可以通过以下方法来实现，例如，使用其内容的第一个散列对文件进行加密，并通过第二个散列对其进行密钥存储-这意味着任何知道文件散列的人都可以检索它，但客户端无法解密它们托管的文件。
一般来说，我建议首先为您正在设计的系统写下一个完整的目标列表，然后寻找一个适合这些目标的体系结构。相比之下，听起来你有一些隐含的目标，并已经选择了一个基本的系统架构-这可能不适合你的全部目标-基于此。