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

我即将开始开发一个应用程序来传输非常大的文件，而不需要任何冲突，但需要可靠性。我希望那些曾经工作过编码这样一个特殊案例的人们了解我将要进入的内容。通过网络传输60GB +文件有哪些选择？

环境将是内网ftp服务器>迄今为止使用主动ftp正常端口的windows系统。我可能还需要在发送之前压缩文件，并且我记得曾经在图书馆工作过一次，会在内存中压缩，并且大小有限制......关于此的想法也值得赞赏。

让我知道如果我需要澄清别的东西。如果有任何细节没有帮助，我会问一般/更高级别的问题。我已经完成了正常大小（高达1GB）的应用程序，但是似乎我需要限制速度，所以我不杀死网络或类似的东西。

感谢您的任何帮助。

来源

2012-09-13 mimoralea

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

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

对于从服务器到单个客户端的传输，我建议您创建一个头文件，其中包含有关文件的元数据，以便接收者始终知道期望的内容，并且知道接收了多少内容，并且还可以检查接收的内容针对哈希的数据。

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

来源

2012-09-13 18:09:10

好的办法。你在哪里学习种子如何工作？你有没有任何有意义的联系？或者我可以购买一本书进一步调查？ – mimoralea

我觉得要走的路是用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的的man页面，这可能会感兴趣：

--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-13 18:19:45 jsbueno

好主意！它甚至不在我的脑海！ – mimoralea

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

回答

相关问题