2

我即将开始开发一个应用程序来传输非常大的文件而不急于但需要可靠性。我希望那些曾经编写过这样一个特殊案例的人能给我一个关于我将要进入的内容的见解。

环境将是intranet ftp server>到目前为止使用active ftp normal ports windows系统。我可能还需要在发送之前压缩文件，我记得曾经使用过一个库，它会压缩到内存中，并且大小有限制......对此的想法也将不胜感激。

让我知道是否需要澄清其他内容。如果有任何不是真正详细的帮助，我正在寻求一般/更高级别的陷阱。我以前做过正常大小（最大 1GB）的应用程序，但这个似乎我需要限制速度，所以我不会破坏网络或类似的东西。

谢谢你的帮助。

4

2 回答 2

1

我认为您可以从洪流中获得一些灵感。

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

对于从服务器到单个客户端的传输，我建议您创建一个标头，其中包含有关文件的元数据，以便接收者始终知道会发生什么，也知道已收到多少，还可以根据哈希检查收到的数据。

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

于 2012-09-13T18:09:10.583 回答
1

我认为要走的路是使用 rsync 实用程序作为 Python 的外部进程 -

从这里引用：

使用校验和将这些片段传输到目标站点中可能存在的文件，并仅传输从目标站点找不到的那些片段。实际上，这意味着如果要复​​制的文件的旧版本或部分版本已经存在于目标站点中，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
于 2012-09-13T18:19:45.107 回答