線上訂房服務-台灣趴趴狗聯合訂房中心
發文 回覆 瀏覽次數:2246
推到 Plurk!
推到 Facebook!

如何保證檔案續傳的一致性!!!

答題得分者是:pcplayer99
wameng
版主


發表:31
回覆:1336
積分:1188
註冊:2004-09-16

發送簡訊給我
#1 引用回覆 回覆 發表時間:2007-07-19 16:23:34 IP:61.222.xxx.xxx 訂閱
當檔案續傳時(暫停後一段時間再 繼續下載)
若此時Server 的檔案發生更新,如何確保所下載的檔案不是錯誤的。

由於若使用MD5 or CRC 還需比對檔案片段,可能頗需耗時。

是否有其他好的Idea !?

使用 HTTP C/S 。
pcplayer99
尊榮會員


發表:146
回覆:790
積分:632
註冊:2003-01-21

發送簡訊給我
#2 引用回覆 回覆 發表時間:2007-07-19 22:26:16 IP:121.35.xxx.xxx 訂閱
如果是你自己做 server 和 client,就容易控制了。比如:

1. 不允许 server 端有相同名字的不同的 file,或者不允许更改 file。
2. 如果 server 的确可能更新一个 file,那么,在 server 端每次更新 file 的时候,计算这个 file 的 hash,把 hash 的 data 保存在 server;client down load 一个 file 的时候首先 download 它的 hash。如果续传,再次download hash 并和本地保存的 hash 对比。其实这里也不一定是 hash,也可以是 version,还可以对比 file 的日期,等等。总之要确定 server 端的 file 就是上一次 download 了一半的那个,并且尽量不要每次对比有关 parameter 的时候都需要重新计算(每次download都重新计算这样比较消耗 CPU)。
wameng
版主


發表:31
回覆:1336
積分:1188
註冊:2004-09-16

發送簡訊給我
#3 引用回覆 回覆 發表時間:2007-07-20 16:47:05 IP:61.222.xxx.xxx 訂閱
現在較麻煩的是
無法確認上次傳到一半的檔案,是跟Server 是一致的。

因為既使保留檔案的Hash值,但在缺了一半的檔案也無法判斷是否為原檔。
除非依據目前下載的部分,由Server 再次產生這個部分的Hash值做為判斷。

並由於缺了部分的檔案是不一定的,也不可能事先處理。

疑惑是難道FlashGet 及 網路螞蟻,都隨便傳一傳。拉勒....

===================引 用 pcplayer99 文 章===================
如果是你自己做 server 和 client,就容易控制了。比如:

1. 不允許 server 端有相同名字的不同的 file,或者不允許更改 file。
2. 如果 server 的確可能更新一個 file,那麼,在 server 端每次更新 file 的時候,計算這個 file 的 hash,把 hash 的 data 保存在 server;client down load 一個 file 的時候首先 download 它的 hash。如果續傳,再次download hash 並和本地保存的 hash 對比。其實這裡也不一定是 hash,也可以是 version,還可以對比 file 的日期,等等。總之要確定 server 端的 file 就是上一次 download 了一半的那個,並且儘量不要每次對比有關 parameter 的時候都需要重新計算(每次download都重新計算這樣比較消耗 CPU)。
pcplayer99
尊榮會員


發表:146
回覆:790
積分:632
註冊:2003-01-21

發送簡訊給我
#4 引用回覆 回覆 發表時間:2007-07-22 17:45:05 IP:59.40.xxx.xxx 訂閱
老兄,你的思路有问题哦。我大概猜到你是怎么想的。

你大概是想这样来做:

假设有个 file,假设它有 1024 byte,你 download 了 500 bytes 到 client。

第2次 download 的时候,你是想先计算 client 端的这 500 bytes 的 hash ,然后让 server 去对比这 500 bytes 的 hash。你这样的想法,当然就要 server 每次都重新计算 hash 了。

但你这样做,其实没有任何意义。假设 server 端的 file 更新了,但前面 500 bytes 并没有更新,更新部分在 file 的末尾,你的做法就检查不到 server 端的 file 的更新。

===================
用 hash 的话,最简单的还是我上面说的办法。

1. server 端的 file 每次更新的时候,要计算自己的 hash,并且把这个 hash 写下来。保证每次 client 来 server 取到的 hash 就是当前这个 file 的 hash ,不需要每次 client 来读当前 server 端这个 file 的 hash 的时候,server 端都要重新计算一次 hash。

2. client 第一次 download 的时候,首先 download 它的 hash 保存在本地。

3. client 第 2 次去 dwonload 剩下的部分的时候,为保证这时候 server 端的 file 和原来的一样没有更新,先把当前的 server 关于这个 file 的 hash 当下来,和保存在本地的这个 file 的 hash 对比,如果不同,则说明 server 端的这个同名的 file 已经不是原来那个了,则不能续传,而需要重新传。

4. 如果下载完成,client 计算 file 的 hash 和保存的 hash 对比,如果不一致,则说明下载过程中出了错,file 的 data 不正确。
pcboy
版主


發表:177
回覆:1838
積分:1463
註冊:2004-01-13

發送簡訊給我
#5 引用回覆 回覆 發表時間:2007-07-22 23:19:15 IP:203.204.xxx.xxx 訂閱
http://filezilla.sourceforge.net/
FileZilla FTP Client 有Source Code可以研究
看看別人如何做的

------
能力不足,求助於人;有能力時,幫幫別人;如果您滿意答覆,請適時結案!

子曰:問有三種,不懂則問,雖懂有疑則問,雖懂而想知更多則問!
編輯記錄
pcboy 重新編輯於 2007-07-23 16:08:58, 註解 無‧
wameng
版主


發表:31
回覆:1336
積分:1188
註冊:2004-09-16

發送簡訊給我
#6 引用回覆 回覆 發表時間:2007-07-23 15:29:33 IP:61.222.xxx.xxx 訂閱
感謝 PcPlayer99 兄,我想我明白該怎麼做了。
有點卡殼!... ~ _ ~ "

再次感謝!

===================引 用 pcplayer99 文 章===================
老兄,你的思路有問題哦。我大概猜到你是怎麼想的。

你大概是想這樣來做:

假設有個 file,假設它有 1024 byte,你 download 了 500 bytes 到 client。

第2次 download 的時候,你是想先計算 client 端的這 500 bytes 的 hash ,然後讓 server 去對比這 500 bytes 的 hash。你這樣的想法,當然就要 server 每次都重新計算 hash 了。

.......................... 簡略
wameng
版主


發表:31
回覆:1336
積分:1188
註冊:2004-09-16

發送簡訊給我
#7 引用回覆 回覆 發表時間:2007-07-23 15:31:16 IP:61.222.xxx.xxx 訂閱
感謝。 我會參考看看...

===================引 用 pcboy 文 章===================
http://filezilla.sourceforge.net/
FileZilla FTP Client 有Source Code可以研究
看看別人如何做的

系統時間:2024-04-28 3:22:27
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!