Slick Forums

This is probably a more difficult task. I am designing an orpg and I would like it to search for available updates on the program splash. I have not done much networking, so this gets to be a learning experience. I am using the Kryonet library.

So I have a server running and the client connects to it on startup. The client then sends an update request to the server with it's version, and if the game is outdated it will send the files it needs to be updated and overwrite the old ones. My problem is the sending files part. Does anyone know a good way to do this?

Well, I believe you can use .jnlp for this. That should work for most cases.


Another approach that I took is on startup:

Get an MD5 of all files and store it in a file: http://www.twmacinta.com/myjava/fast_md5.php

Download a list of current MD5s from http (generated by a script)

Compare the local list with the remote list.

If anything is missing or md5 is different than download compressed file via http.
If anything is on local list but not in remote list (and not in 'mod' or user directory) then delete it.

I used 7zip for compression: http://www.7-zip.org/sdk.html

I used http because it was simple and fast and took load from the game server.

The benefits of this are:

1) It only downloads changed/missing files

2) It's fast

3) uses standard/open libraries and http server (which is cheap bandwidth compared to a "game server")

4) It's easy to thread out if you want to make it faster

5) The only thing the player needs is the startup/launcher program. From there it can keep it's self up to date.


The downside:

1) During an update, your http is going to get slammed.

2) .jnlp already has most of this functionality built in.



To get around slamming your http server, you could have a 'pre-release' directory that has the files and then download them in a throttled and controlled manner days or weeks before the real release.. Then at release time, check the pre-release directory first (before downloading via http).

You could try getdown too, it is more customizable than Java Web Start and it has the features you are looking for. It is being used by Spiral Knights for example.

_________________

Hmmm, thanks guys. I will try using both and go with whatever works best. These are exactly what I was hoping for.

Hey,
sorry for the topic bump, but my question fits in with what has been postet here.

I am programming a game engine that makes use of Slick and I am thinking about how to solute a Updater API since multiple weeks. My API currently works like dime said - except that I prefer to not compress the data,

and I can't find the best way to patch the main-jar itself. The updater is part of an API and won't force devs who want to use my API to create a seperate program as launcher / patcher, i need a way to let the executed program patch itself.

I could update main.jar by downloading the new instance as mainNEW.jar, then mainNEW.jar gets executed by the running main.jar and mainNEW.jar forces main.jar to close. Secondly, mainNEW.jar notices that its name is not "main.jar" and downloads a new instance as main.jar, then main.jar gets executed and kills mainNEW.jar,

but this way seems not to be that efficient. Is there a solution for the problem? How does getdown handle that?

I plan on going with a simple incremental patcher. It starts off with 0.patch to 9999.patch or more. The client would store the last .patch increment in a .dat file to determine the next increment. So if the last patch was 99 the client would know to ask if patch 100 exists and then it repeats this after patch 100 has downloaded. If the user has 0.patch and the newest patch is 100.patch then the server knows.. "we need to get patches 0-100 for this user from the file database."

In the .patch file you'd have a list of md5 checksums for all the files for validation so every time the client starts the updater you'd check the validation of the last .patch and make sure the files are all there otherwise you redownload that patch. Sorry if this is confusing you.

1. Download patch 99
2. Install patch 99
3. New patch 100 found
4. Scan patch 99 md5 checksums if fail goto step 1
6. Download patch 100.
7. Install patch 100.
8. New patch 101 found
9. Scan patch 100 md5 checksums if fail goto step 6

I like this approach to updating very much because its simple and most users will know what is going on.

Unfortunately mine is in C# but the same idea can still be applied to java.