3

I saw it in a presentation a few weeks back, tried to implement it, failed and forgot about it. But now I wanna know how it works =)

It's a way of efficiently transfering/storing data. It would work in any language. This is what (I think) it does:

You have 1 very big file (eg entire javascript collection of a website).

  1. Split it in blocks of 48 bytes
  2. Hash every block of 48 bytes (eg. MD5)
  3. Split the list of blocks on hashes that end with 0x00
  4. The big blocks (>= 1 hash) should now be different sizes. Some very big, some very small.
  5. Glue the blocks between those hashes (again: very different sizes of actual data)
  6. Hash those blocks
  7. Now you have a list of hashes that represent the current version of the big file

The idea is that when a piece of code changes in the big file, only 1 or 2 hashes change. With the new file, you do all those above steps and you only upload/download the parts (blocks, identifieable by its hash) that have actyally changed. Depending on how much code was changed and on the size of the blocks surrounding that code, you'll never need to download more than 4 blocks. (Instead of the whole file.) The other end of the communication would then replace the original blocks (same algorithm, same functionality) with the new blocks.

Sound familiar? They mentioned a name, but couldn't find anything on it. When I tried to build it, it just didn't work, because if you don't change exactly 48 bytes [1], ALL the hashes after that change [2] are different...

If someonw knows the name: great. If someone could explain it also: perfect!

UPDATE
I found the presentation it was in. It was mentioned (and is used) in a new product "Silo": http://research.microsoft.com/apps/pubs/default.aspx?id=131524 Related: http://channel9.msdn.com/Events/MIX/MIX11/RES04 (So it actually was Microsoft research! Neat!)

From the first link:

A Silo-enabled page uses this local storage as an LBFS-style chunkstore.

In the second link (a video), the good stuff starts at 6:30. Now I've seen it twice... I still don't get it =)

Keywords are Delta encoding and Rabin fingerprints.

Rudie
  • 52,220
  • 42
  • 131
  • 173
  • 2
    Most likely you remember some details wrong as here if you insert a byte at the beginning of the file all hash values change. It could be that you should hash EVERY run of 48 bytes instead of blocks. – Antti Huima Apr 30 '11 at 16:50
  • Yeah I know =) That's where I got stuck! But hashing every run of 48 bytes is hashing as many times as the file big is in bytes - 47. (That's 10's if not 100's of 1000's!) That can't be it. Then it's just not worth it anymore!? – Rudie Apr 30 '11 at 17:28

3 Answers3

3

This sounds ... kind of ... like how remote differential compression works;

In the Low Bandwidth File System (LBFS) [24], an RDC protocol is used to optimize the communication between a sender and a recipient by having both sides subdivide all of their files into chunks and compute strong checksums, or signatures, for each chunk. When a client needs to access or copy a file from the server, the latter first transmits the list of signatures for that file to the client, which determines which of its old chunks may be used to reconstruct the new file, and requests the missing chunks. The key to this protocol is that the files are divided independently on the client and server, by determining chunk boundaries from data features.

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

Alex K.
  • 171,639
  • 30
  • 264
  • 288
  • It does kind of sound like it. I remember (but I don't) a more exotic name though... I'm looking for the presentation it was in. – Rudie Apr 30 '11 at 17:31
3

You can solve the "changes which aren't a multiple of the block size" problem using rolling hashes. This is what rsync uses to transfer only changed parts of a file.

Keith Randall
  • 22,985
  • 2
  • 35
  • 54
  • +1 for `rolling hashes` and `rsync` =) That's probably what they meant. Sounds like a lot of work to me though... – Rudie Apr 30 '11 at 17:45
1

That sounds very much like shingling.

Jim Mischel
  • 131,090
  • 20
  • 188
  • 351