這個哈希/緩存/版本控制算法的名稱是什麼？

幾周前我在演示中看到它，試圖實現它，失敗並忘記了它。但現在我想知道它是如何工作=）這個哈希/緩存/版本控制算法的名稱是什麼？

這是一種有效的傳輸/存儲數據的方式。它可以用任何語言工作。這是什麼（我認爲）它：

你有1個非常大的文件（例如一個網站的整個JavaScript集合）。

拆分它的48個字節
散列塊的48個字節的每個塊（例如MD5）
分割塊上用0x00
大塊結束散列列表（> = 1散列）現在應該是不同的大小。一些非常大，一些非常小。
（再次：實際數據非常不同的大小）膠的哈希值之間的塊
哈希那些塊
現在你有代表的大文件的當前版本的散列的列表

這個想法是，當大文件中的一段代碼發生變化時，只有1或2個散列會發生變化。使用新文件，您可以執行上述所有步驟，並且只上傳/下載實際更改的部分（塊，可通過其散列識別）。根據代碼的變化情況以及該代碼周圍塊的大小，您永遠不需要下載超過4個塊。（而不是整個文件）。通信的另一端將用新塊代替原始塊（相同的算法，相同的功能）。

聽起來很熟悉嗎？他們提到了一個名字，但是找不到任何東西。當我試圖構建它時，它只是不起作用，因爲如果你不改變正好48個字節[1]，那麼在所述改變[2]之後的所有哈希值是不同的...

如果someonw知道名字：很好。如果有人可以解釋它：完美！

UPDATE
我發現展示它在它的新產品「筒倉」提到（和使用）：http://research.microsoft.com/apps/pubs/default.aspx?id=131524相關：http://channel9.msdn.com/Events/MIX/MIX11/RES04（！所以這實際上是微軟研究純）

從第一環節：

啓用倉-A頁面鏈接到本本地存儲作爲LBFS式chunkstore。

在第二個鏈接（視頻）中，好東西從6:30開始。現在我已經看到了兩次...我仍然沒有得到它=）

關鍵字是Delta encoding和Rabin fingerprints。

來源

2011-04-30 Rudie

如果你在文件的開頭插入一個字節，所有散列值都會改變，你很可能會記得一些細節錯誤。這可能是你應該散列每個48字節而不是塊的運行。 – 2011-04-30 16:50:35

是的，我知道=）這就是我卡住了！但是，每次運行48個字節時，散列的次數與文件大小以字節爲單位 - 47次相同。（如果不是1000年的100個，那麼這個數字就是10）！那不可能。那麼它就不值得了！？ – Rudie 2011-04-30 17:28:31

這聽起來......有點......比如遠程差分壓縮如何工作;

在低帶寬文件系統（LBFS）[24]，一個RDC協議由具有兩側細分所有其文件的成塊用於優化發送方和接收方之間的通信並計算每個塊的校驗和或簽名。當客戶端需要訪問或從服務器複製一個文件時，後者第一該文件到客戶端，它確定哪一個其舊塊可以被用來重建新文件發送的簽名列表，並請求丟失的塊。這個協議的關鍵在於通過確定數據特徵的邊界，在客戶端和服務器上獨立劃分的文件是。

PDF http://research.microsoft.com/apps/pubs/default.aspx?id=64692

來源

2011-04-30 16:36:06

它聽起來很像它。我記得（但我沒有）一個更具有異國情調的名字，雖然...我正在尋找它的演示文稿。 – Rudie 2011-04-30 17:31:43