Online Patching Systems?

Master_Flash asks: "My company is preparing to distribute an online Windows application that will change over time (don't they all?). We been evaluating online patch systems. There are a number of commercial applications out there. Some look good: RTPatch from PocketSoft, ASTA Binary Patcher, and Necromancer's FlashUpdate. Has anyone had a positive experience with these or other applications? One other idea we had was to use CVS as a patching system. While CVS isn't technically a binary patch it does a great job at checking on which files need to be updated. Most of the files we have are small and change infrequently, so CVS could work. Opinions and guidance are welcome."

Comments

Not CVS!

[moosesocks]

CVS is overly bandwidth and cpu-intensive both client-side and server side. I believe that there are various forks of it which are more efficent.

But, I digress. CVS was not designed for this. Rsync was designed almost percisely for something like this. It only transferres the parts of the file which have been modified, and compresses it as well.

But, why not simply use installshield or a similar tool like all other windows developers and just release periodic updates (which fits the model for windows software, which, IMO is quite diferent than the linux model (make many releases and many patches, while windows and MAC lean twoard making a few periodic releases, only patching where there is a severe flaw).

I'm not saying that one model is any better, i'm just saying that you need to keep consistancy.

Roll Your Own!

[billcopc]

I made a very simple live update system way back. It involved having all the latest files on a network share. Quite simply, every time the application was launched it would check that share for any files newer than its own and copy them over (thanks to a 30kbyte stub loader). Result: anyone who used my software was assured to have the latest version, and as a bonus if they were using it and it crashed, chances are they'd get a fix when they tried to reload it :)

I later used a variation on that scheme that involved a cron job on the server, checking regularly for new commits to the shared folder. It would then calculate windowed hashes of each file and the client update app would simply compare the server's hashes with its own (cached) hashes. This enabled me to minimize download times since it would only download the chunks that had been changed (in the case of large data heaps). It's not foolproof since I didn't do any insert/delete logic (add 1 byte to the beginning of the file and the rest is immediately invalidated)... but it was simple enough to justify the occasional forethought when releasing updates. It's like a castrated embedded version of rsync :) Damned easy to code too.

Considering the hell I've been thorugh with RTPatch and its ever-flaky software, it would be well worth writing my own smart binary diff (with proper shuffling detection and compression). These things really aren't that complicated to implement and the advantage of rolling your own is that you can include extra logic tailored for your application (or for that particular client).