JZIPUpdate

• What does it do?
• Features
• Documentation
  • Requirements
  • How to Use
  • How it Works
  • Java Docs
• Screenshots
• Download
• Licensing and Usage
• Development
  • Upcoming Features
  • Planned Features
  • Known Bugs
  • Change Log

Hosted by

How it Works

To minimize data transfer over the network, JZIPUpdate issues only two HTTP requests and transfers all data in compressed form. Here's how it works:

• An ZIP or JAR archive is indexed and both the archive and its index file are moved into a web-accessible location, e.g. uploaded to a web server. This step needs to be done everytime a new or updated archive gets deployed.
  I'll provide a servlet soon that will automatically generate an index file for archives if there's none or if it's outdated.
  The index file contains the name, CRC checksum and the end offset of each ZIP entry in an archive; this is just enough information to compare and download individual ZIP entries later on.
  

1. The client starts by reading the names and CRC checksums of all ZIP entries in the archive it is supposed to update.
2. The client requests the index file from the specified URL, by appending .idx to the the URL, e.g. for http://www.example.com/files/monkey.zip the client will expect the index file at http://www.example.com/files/monkey.zip.idx.
3. The client-side pairs of ZIP entry names and CRC checksums are compared to the server-side pairs from the index file. This results in a diff-like set of patch instructions like:

   	
   	ADD /sounds/dog.ogg
   	UPD /sounds/cat.ogg
   	REM /images/donkey.jpg
   	NOOP /textures/monkey.jpg
   	
   	

   Actually, resources flagged as NOOP are removed from the diff, to decrease its size and to speed up lookups.
4. Resources flagged as ADD or UPD are downloaded from the web server:
   • Using the end offsets from the index file, a special HTTP byte-range request is built which requests exactly the portions of the archive from the web server that contain the required ZIP entries, including all ZIP file headers for an entry.
     Byte-range requests are a feature of HTTP 1.1 usually used by browsers or downloads managers to "resuming" downloads.
     Due to the ZIP file format's serial and self-contained structure, a "local file block" is enough to reliably extract the actual data and verify its integrity.
   • The web server replies with a MIME Multipart response, with each part corresponding to one of the requested ZIP entries. That MIME message is then parsed, split up and its data payloads are fed to a custom ZIP parser that is able to extract stand-alone local file block of ZIP files.
   • While the downloaded data goes into the client system's temp directory to achieve higher download speeds and avoid hassles with timeouts, the parsing and extracting is done on-the-fly when the archive gets patched.
5. Now that both the client-side and server-side resources are available on the client, the patching begins:
   A temporary ZIP file is created and all resources flagged as NOOP are copied over, resources flagged as REM are skipped. Resources flagged as ADD or UPD are taken from the multipart response sent by the server.
6. Finally, the original archive is deleted and the temporary ZIP file is moved into its place, and the unparsed multipart data is removed from the system's temp directory.