Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

What's the difference between zsync and jigdo? Their core functionality seems the same, so I'm curious on things like performance, file size, and ease-of-use. Would also be interesting to know why one got created when one already existed.

share|improve this question
add comment

3 Answers

up vote 2 down vote accepted

IIRC, Jigdo allows you to break out the files within an ISO and pull the individual files from other servers.

Case in point: Jigdo used to be the preferred way to get Debian ISO files. The Jigdo config file you downloaded would direct the Jigdo client to download all of the files from the regular distribution servers/mirrors, using FTP or HTTP protocols. Then, it would build the ISO client-side. It could start with an existing ISO and "update" it or add stuff which you didn't have time to download and add in, earlier. However, if one of the .deb files (which are compressed) in the ISO changed, you had to download the entire .deb file to rebuild the ISO.

RSync looks at what you have downloaded and what is "current" on the server, downloads the diffs and patches the file(s). Consequently, if you have 650 MB ISO file downloaded, running RSync against it and a server-side version of the ISO file will only download what changed. That allows you to "maintain" a folder or file, relative to another server. That server, however, needs to support the RSync protocol and it will have a pretty high CPU load anytime someone wants to sync with it. Finally, it doesn't work so well for compressed files, because a small change to the uncompressed version can cascade to some VERY significant changes to the compressed version. Consequently, changing a couple files within a .deb file in the ISO will result in downloading the entire new .deb file, not unlike with Jigdo.

ZSync works over HTTP, so no special protocol support is needed. ZSync pushes the CPU load down to the client, instead of the server, so it works better when you have large numbers of users syncing against a centralized server. Finally, small changes to the uncompressed versions of files will result in very small downloads over ZSync, even if the resulting, compressed file has significant changes. If you have an ISO containing thousands of .deb files and you change a few files within one of the .deb files, ZSync would a download just enough information to patch the out-of-date .deb file and re-compress it as needed, then verify the CRC or MD5 signatures, and be done with it. Less bandwidth used, less server-side CPU used, no special protocols needed.

When they can merge all of this with BitTorrent, they've got a winner. When that happens:

  1. syncing with the server will tell you what changes you need
  2. peers will provide all of the data, served up in parallel, ensuring maximum speed on the total download
  3. checksums and hashes from the server will ensure that no peers provide bogus data

That would use even less bandwidth on the server and result in even faster updating. Does anyone know of a protcol/system like that? Last I checked, BitTorrent doesn't allow you to "update" an existing copy of a file.

share|improve this answer
    
That last bit is worthy of being asked separately, perhaps on a larger site like Stack Overflow. –  Tshepang Mar 26 '12 at 9:36
add comment

jigdo can be difficult to use. In today's world, if you need distributed file distribution (boy, doesn't that sound just plain odd) it is probably best to use BitTorrent. It may not do all that great for updates, or incremental improvements, but it's a helluva way to distribute the load across the entire Internet, of course given enough participation.

If what you need is a means by which to do incremental updates, perhaps as a central mirror to fan-out sites, or even from a collection of mirrors to end-users, I'd recommend using rsync's daemon mode to expose modules that can be synchronized.

Honestly, what tool to use depends on your audience, though I can say that if your audience are not a patient bunch, jigdo is most likely out of the question entirely.

share|improve this answer
    
I thought jigdo was hard, until I used it again: (1) select jigdo file from web; (2) on CLI, run jigdo with that jigdo file as argument; (3) jigdo will prompt you if there is an iso mount you want to add the new iso. –  Tshepang Dec 17 '10 at 9:27
add comment

For a new project, using actively developed software will have many advantages over frozen software. What will your project need in a year, and will Jigdo provide that new functionality?

Now, I couldn't find evidence to back this up so someone please correct me. I believe that:

  • jigdo allows clients to download chunks from multiple, different mirrors, similar to bittorrent. This greatly reduces the load on the central mirror.
  • zsync is designed for a single, central mirror.
share|improve this answer
    
So in a way, you could state that bittorrent supersedes jigdo. –  Gert Dec 17 '10 at 11:04
    
@Gert: Bittorrent will download an entire ISO. As I understand it, Zsync and jigdo will only download the parts of the ISO which have changed between releases. This can be a significant difference between download times. However, jigdo and zync have only been implemented for a handful of projects, while bittorrent is more widely used. –  Stefan Lasiewski Dec 17 '10 at 19:00
    
I don't think ur edit is accurate. jigdo is much closer to zsync that it is to bittorrent. Both rely on some central server (or it's mirrors), while bittorrent is decentralised. –  Tshepang Jan 18 '11 at 20:38
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.