JZIPUpdate
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.
-
The client starts by reading the names and CRC checksums of all ZIP
entries in the archive it is supposed to update.
-
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
.
-
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.
-
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.
-
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.
-
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.
Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.