对于一个可以恢复文件传输的点对点应用程序,在恢复文件之前检查文件大小/修改日期是否足够?



我正在开发一个具有点对点文件传输组件的网络应用程序(想想即时信使),我希望使它能够优雅地恢复文件传输。

如果有一个正在进行的文件传输,并且一个用户退出,接收方仍然知道他成功接收了多少文件,因此从哪里恢复传输。但是,如果文件在此期间发生了更改,如何检测到这一点?关于我的问题,我在这里关注的不是网络的破坏,而是源文件被修改的破坏。

我开始的方式是让发送方在发送文件之前对文件进行哈希,这样接收方就有了一个哈希值来检查完成的文件。但是,这只能在最后检测到损坏,除非每个resume也散列。这个问题可以通过查看文件块,并对每个块进行散列来缓解。然而,散列更大的问题是,它可能会花费非常非常长的时间,当用户只是想立即发送某些东西时,这只是一个糟糕的用户体验(例如:在慢速网络上共享Linux ISO是要发送的文件)。

我正在考虑更改为每次传输开始或恢复时简单地检查文件大小和修改日期。虽然这显然不是万无一失的,除非我遗漏了什么(如果我遗漏了什么,请纠正我),但最终用户用于修改文件的几乎所有方法都是正确的,并且至少标记了修改日期,即使没有,大小的更改也应该捕获99%的情况。这看起来像是一个可以接受的妥协吗?坏主意?

现有的协议如何处理这个问题?

对您的问题的快速回答是,它在大多数情况下都可以工作,除非文件经常被修改。

不要使用哈希,而是使用校验和(例如CRC32)。这样可以更快地检查文件是否被修改。

如果连接中断,您只需要将计算出的块校验和发送回源,源可以计算当前块是否在两者之间被修改。然后,它可以决定重发哪一个并发送丢失的块。

块,在用户体验方面,校验和是比完整文件和散列更好的折衷。

最新更新