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.
Tell me more
×
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.
|
|
||||
|
|
|
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:
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. |
|||
|
|
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. |
|||
|
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:
|
|||||||
|
