Question

我即将开始开发一个应用程序来传输非常大的文件而不需要任何热情但需要可靠性。我希望那些编写了这样一个特定案例的人能够让我了解我即将进入的目标。

环境将是Intranet ftp服务器＆gt;到目前为止使用活动的ftp普通端口windows系统。我可能还需要在发送之前压缩文件，我记得曾经使用过一个可以在内存中压缩的库，而且大小有限制......对此的想法也会受到赞赏。

如果我需要澄清其他内容，请告诉我。如果没有真正详细的帮助，我会要求一般/更高级别的陷阱。我之前已经完成了正常尺寸（最高1GB）的应用程序，但这个应用似乎我需要限制速度，所以我不会杀死网络或类似的东西。

感谢您的帮助。

Answer 1

我想你可以从种子中获得灵感。

Torrent通常会将文件分解为可管理的部分并计算它们的哈希值。后来他们一块一块地转移它们。每件作品都经过哈希验证，只有在匹配时才接受。这是非常有效的机制，让转移从多个来源发生，并且让重新启动任意次数，而不必担心数据损坏。

为了从服务器转移到单个客户端，我建议你创建一个包含有关文件元数据的标题，这样接收者总是知道会发生什么，也知道收到了多少，还可以检查收到的数据反对哈希。

我在客户端服务器应用程序上实际实现了这个想法，但是数据大小要小得多，比如1500k，但可靠性和冗余是重要的因素。这样，您还可以有效地控制您希望通过应用程序允许的流量。

Answer 2

我认为可行的方法是使用rsync实用程序作为Python的外部进程 -

引自here：

使用校验和的片段到目标中可能存在的文件站点，并仅传输那些未找到的碎片目标网站。在实践中，这意味着如果年龄较大或部分要复制的文件的版本已存在于目标站点中， rsync仅传输文件的缺失部分。在许多情况下这使得数据更新过程比所有文件都快得多每次源和目标站点同步时都不会复制。

你可以使用-z开关动态地进行压缩，以便透明地进行数据传输，无需在任何一端压缩整个文件。

另外，请在此处查看答案： https://serverfault.com/questions/154254/for-large-files-compress-first-then-transfer-or-rsync-z-which-would-be-fastest

从rsync的手册页中，这可能是有趣的：

   --partial
          By  default,  rsync  will  delete any partially transferred
          file if the transfer is interrupted. In some  circumstances
          it  is  more desirable to keep partially transferred files.
          Using the --partial option tells rsync to keep the  partial
          file which should make a subsequent transfer of the rest of
          the file much faster

通过网络传输60GB +文件有哪些选择？

2 个答案: