- #RUNESCAPE 718 REALISTIC SERVER PRIVATE CACHE CLIENT ARCHIVE#
- #RUNESCAPE 718 REALISTIC SERVER PRIVATE CACHE CLIENT SOFTWARE#
- #RUNESCAPE 718 REALISTIC SERVER PRIVATE CACHE CLIENT ZIP#
I might also allow read-only public access to the underlying Postgres database in the future, but I've got to think a bit carefully about security and this would be subject to nobody abusing it (e.g.
#RUNESCAPE 718 REALISTIC SERVER PRIVATE CACHE CLIENT SOFTWARE#
The software you need to export caches from a mirrored copy is available at. This is much more efficient than downloading all the caches/keysets individually. What I might end up doing is showing a list of colliding groups in the web interface and punting the problem to the users.Ī complete backup of the database is taken daily and made available over rsync/HTTP (rsync:///pub/db/, ), in case anyone would like to maintain a mirror of the whole thing. I'm thinking of ways to improve this, but it is tricky - deciding which copy of the file is correct for a particular version of the cache probably can't be automated.
#RUNESCAPE 718 REALISTIC SERVER PRIVATE CACHE CLIENT ARCHIVE#
At the moment, the archive doesn't deal with collisions particularly well - for colliding groups, it prefers the first variant imported. Luckily I haven't found any collisions in OSRS caches yet, so hopefully they've fixed it there. My suspicion is that Jagex only incremented the version number if they detected a change in the CRC-32 checksum, rather than comparing the uncompressed content (or a secure hash of it) directly. some newer versions of the cache containing older variants of a colliding group, with others containing the new variant and no particular pattern to it). I can actually see this in the data I imported (e.g. Users with the old variant of the group wouldn't receive updates. Unfortunately, Jagex didn't increment the version number for these changes, and this would have in fact caused problems at the time: depending on when you first downloaded the cache, you might get an old or a new variant of the group. As GZIP has a CRC-32 trailer, any changes to the uncompressed data are actually cancelled out by the trailer (due to an unfortunate property of the CRC algorithm), rendering the overall CRC-32 checksum unchanged. Some of the GZIP-compressed containers use the stored compression level (no compression). One known problem at the moment that I'm still fixing is that there are a small number of (archive, group, checksum, version) collisions (8 across the entire database at the time of writing). This allows us to eke out as many validated keys as possible. As many of the old dumpers didn't record the region ID for dynamic regions correctly, the service verifies every candidate key against every encrypted group for every version of the cache (and all future caches when they are imported).
#RUNESCAPE 718 REALISTIC SERVER PRIVATE CACHE CLIENT ZIP#
I'll add support for downloading a ZIP of text files in the future too. XTEA keys are automatically verified and they can be downloaded as a JSON file for every cache present in the archive. An alternative flat file format will be added for caches larger than 8GB (the max size of the. dat2/.idx on demand when a cache is downloaded. * Missing groups and keys can be located from nearby caches, as long as the checksum and version number are identical. Storing all these caches individually would use over 850 GB! The database backups (which are compressed and omit the indexes) are even smaller - around 36 GB at the moment. Currently it uses 66 GB to store over 670 caches for a mixture of mainline RS and OSRS builds. The groups are stored in a content-addressable format (based on (archive, group, checksum, version) tuples), which provides several benefits: Unlike the existing archives, it's backed by a database - not a collection of static files. It automatically downloads new OSRS and RS3 caches when they are released and pulls OSRS XTEA keys from various sources. Support for archiving clients/native libraries is planned in the future. It's currently a collection of caches and XTEA keys for all versions of RuneScape that use JS5, and its precursor, to manage assets (mainline RuneScape build 234+ and all builds of OSRS).
I've been working on this service for a while now, and it's now ready to be announced publicly (though there's still lots of work to do!)
0 kommentar(er)
