Automatic Updates via Internet

[TheTuna]

Sorry this is so long...

I'd like to discuss solution ideas for performing automatic software updates across the internet. My current project will be in hundreds of locations across the country (kiosk units, unattended).

Pretty much once they are in the field, nobody can service them. I'll be installing some kind of remote access program, like PCAnywhere, just in case, but I'm working on an idea for sending executable replacements, component replacements, image files, audio files, etc.

Here's the basic plan:

A auto-update program will be scheduled to check for updates on a set interval, and it will also monitor an FTP site for new files.

In a perfect world, these internet enabled kiosks would all have broadband connections, but it's impossible, since nationwide coverage of broadband isn't here yet. So, some kiosks will connect using dialup ISP's, or RAS to our server. (I kringe at the thought of using any dialup).

Large files will need to be compressed, using the zip protocol.

Using winsock, I can easily signal the kiosk to use an Inet to download a package of files or single files, and I can use executable zip files to put files in the correct paths/folders. I can use a Shell command to register ocx's or dll's.

I would imagine I'll need to allow the autoupdate app to shut down the main executable and re-start it when the version changes.

Am I missing anything? See any less obvious obstacles (other than connection issues with dial up)? Past experiences that might help me avoid mistakes that have already been made?

Thanks for reading, I know this was a long-winded post...

oh yeah, operating system on the kiosks is windows 2000. I'll have to shut off messaging services due to pesky popups. (dont you hate those suckers?)

Discussion is welcomed! No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[skiflyer]

"Can anybody think of a way around the absence of static IP address? "

Why bother using an IP address at all? I'd definately go with a webserver for this type of thing, then you can just register a domain name, and you're all set. Change providers all you want, just keep the domain name. If for some reason this needs to change, you'd just need to have both going for a set amount of time, and the update from the old one would have to include the name of the new one.

And I also avoided XML in the beginning of mine, but by the end I realized it was silly, so I just learned it and put it in, saved myself alot of hassle... but yours sounds slightly more straightforward in as much as you'll be maintaining the update server, so you should be fine... I had to also make a frontend that could be shipped out with the update server.


And benny,
The client just reads a URL which contains plain text or an XML file, and parses out the information it needs from there to know what versions or other instructions exist on the server. Then it runs all the comparisons it needs to and downloads what it wants. The logic goes in the client, so as Tuna said, the client is responsible for itself, and the server is responsible for itself instead of trying to keep track of everyone else.

-Rob
(sorry I get less and less coherent as my week progresses)

 

[bennynye]

skiflyer -

It's so simple. I thought I was going to get to use my first SOAP application. That's too bad. Thanks for simplifying this app anyway.

Bennynye

 

[TheTuna]

skiflyer- Lucky for me, I have 5 Static IP addresses... and yes, using a web server is arguably the best solution as you said.

But since I know so little about XML, it hasn't made sense to me to even consider using it when I already know how to do this with VB and the Win32API. Can you outline for me the benifits of using XML, and provide some detail as well? I don't want to be close-minded about the project. Keep in mind that I MUST balance URGENCY of NEED vs. AN OPTIMAL WIDESPREAD solution. i.e. There's no time to learn XML, yet soon there will be, and I can then upgrade to XML if it truly is what you say. (not doubting you, of course)

Thanks! No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[skiflyer]

It all depends how you do it... I found I could do 90% of what I wanted with plain txt and ini files, but as the requirements phase got more and more fluid, I got tired of being creative with my ini files and said, you know what, gimme an extra day I'm switching this stuff over to XML.

But just out of curiosity of how you want to do it with VB & Win32API I want to lay out my assumptions and questions for what you're doing...

1) WinAPI get's the version of the local executable.
2) How do you determine the version on the server?
3) WinAPI (assumably InetControl) downloads the update.
4) Something like Shell() runs the update.

So to answer your questoin, I used XML for step 2. I had to worry about people who would want to roll updates out to specified IP ranges, but not others, who wanted to keep histories of their updates, who wanted certain updates optional, certain mandatory, certain marked as rollbacks. They wanted to be able to manage multiple versions of multiple products by IP address and product name. To manage all that information I used XML, to actually update the program, it's like you said... VB, some text files, and a webserver... plus I have one C++ app in there because I use BITS to download the updates (which is nice because it takes care of dropped connections and that type of stuff)

-Rob

 

[TheTuna]

Error correction:

Upon success or failure of the script, the client signals the server the status of the update and returns the script to the server (if requested).

Should read:

Upon success or failure of the script, the client signals the server the status of the update and returns the LOG to the server (if requested). No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[TheTuna]

Well, see, that's exactly why I started this thread...

It's easy for me to focus to tightly on what I need, and forget that I'll probably need something else sooner or later...

That's a very good point Rob. As of now, every kiosk we'll have in the field should be running the same version all the time. But in the future, that could very well change. Specifically, in the future, I'm sure that the video advertisements that run will become regionally and eventually locally diversified. Meaning I'd want to send different advertisement packages to any number of clients.

OK, I did consider this, which is why I had the client checking in regularly. When a client checks in, it identifies itself, and would be given it's specific package location.

Ok, I'm gettind dizzy agian.

No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[skiflyer]

Which is why I'd strongly consider giving the updater the ability to update itself!

Actually, there's a good chance you'll do just that accidentally (I did )... in which case, you just need to make it work that well, and satisfy your immediate needs... and the rest when you have time.

-Rob

 

[TheTuna]

Sorry SkiFlyer, I didn't answer your questions...


"2) How do you determine the version on the server?"

For my needs, the server doesn't need to know anything other than what it is told to do. The server uses a simple database, so when client "XPClient201" checks in, the server does a query and if it finds an update for "XPClient201" it can provide the URL to the Client. The client must then take action on it's own.

3) WinAPI (assumably InetControl) downloads the update.

EXACTLY!

4) Something like Shell() runs the update.

That's part of it... remember, the client will in essence be a script language interpreter. It reads a line from the script, interprets the code and performs the task. When done, it reads the next line of code, continuing until it reaches the end.

Shell() would be used to restart any executables that were killed priviosly in the script... AppActivate would also be used if needed.

No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[SemperFiDownUnda]

The best examples of this I know of are game patchers for MMO games like EQ, AO, DAOC.

Let me go into EQ patcher because this is the most robust that I've seen.

The patcher first checks for a new version of itself. It now replaces and reloads itself without user intervention. The patcher then grabs an XML file from the server. It uses this XML file to
1) check for missing files
2) check for new or newer files
then starts downloading the files via HTTP
It happens to download GZIPed files and via other information in the original XML file knows the name and location on the server and the name and relative location on the client the file belongs

Also the patcher has the ability to only check for certian groups of files by basically just skipping ones you are not interested in. In their case it is expansions you may not have bought.

lastly the patcher has a more involved way of checking file integrity using checksum also available in the original XML file. This takes longer but assures that the file is the same as the server copy without having to copy the server file down.

While the patcher is running you can display readme, updates, what ever. This to me is a great patch system and most of the MMO games follow this and it works well. EQ alone has almost a half a million accounts patching in this manner.

If you have custom patch systems the XML the client recieves could easily be generated uniquely for that client.

 

[skiflyer]

the updater for the front end to Gemstone III was actually my original motivation... granted company specs eventually took me far from it.

 

[TheTuna]

And yes, I too am a gamer, but I play UO...

I see the point now about the updater first checking if itself should be updated! That I can do, too.

Thanks, good point SemperFi. No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[TheTuna]

Well, this may actually be complete by tonight... No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[TheTuna]

I took the weekend off, but I've started working on the update application again.

I'm adding the ability to create folders but so far, here's what the script language recognizes: all functions are case INsensitive at this time.


Pause (milliseconds)
Uses Sleep API to acheive this task (tested successfully)
CloseApp (windowname)
Uses SendMessageByNum by sending WM_CLOSE to handle retreived using FindWindow... (tested successfully)
StartApp (path & filename, SwitchTo)
Uses Shell and if SwitchTo is True, will AppActivate as well
LockInput (mode)
Mode True then BlockInput locks it, mode false unlocks (unlocks automatically in 60 seconds, and on any error, and on unload... I'm thinking about setting an interval option to allow you to assign an emergency unlock for up to 10 minutes from initial LockInput True) Tested Successfully but changes are pending.

Here's what else I'll be working on tonight, but these are not implemented yet.

iNetGet (url as string, filename as string, savepath as string, saveas as string, retrycount as integer)
This will use Inet control to get a file from the url specified and upon success will write the file to the savepath using the saveas as the filename.)

MakeLog (pathandfile as string)
Needs little explination- For now, this will just write the instruction to a text file at the path specified, later will indicate success or failure, but failure will probably abort the process anyway, so is it worth it?)

There's more to come beyond this... but not tonight. No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[skiflyer]

StartApp (path & filename, SwitchTo)
Uses Shell and if SwitchTo is True, will AppActivate as well

----------

I might suggest using WinExec instead of Shell... I found Shell has the peculiarity to hide certain error messages on launch.... namely missing or malformed or unregistered DLL's.... can be a big pain for anyone who has to debug the thing... and since WinExec has effectively the same syntax is an easy switch.

-Rob

 

[TheTuna]

Thanks Rob... I'll look into it. No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!