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!

 

[DrJavaJoe]

I'm in the same boat we are considering using InstallShields Update Service. Here's a link to read more. The thing is it cost $600 per year for 5000 users. I'm interested in seeing other option though.

http://www.installshield.com/isus/

 

[TheTuna]

Thanks for the link, but I don't think this is the solution I'm looking for. I'd much rather write a few utilities on my own... The chance of having something go wrong and be totally out of my hands to fix seems too risky. I'd feel safer screwing it up myself...

If I plan this out correctly, I should be able to write an auto update system that would work for just about any application.

Please remind me of anything I might be missing from the following list (when this is done I'll share the source code with anyone who wants it)

1. Script Language Requirements
a. Register OCX/DLL
b. Rename an existing file
c. Delete an existing file
d. Move an existing file
e. Copy an existing file
f. Replace an existing file (oldie, newbie)
g. Backup / Restore
h. Shut Down a process or application
i. Launch / Restart an application (i.e. shell)
j. Pause (with timer in milliseconds)
k. Determine if app/process is running
l. Simulate keystrokes & mouse activity (respond to dialogs)
m. Report status/completion to server (using Winsock, must have something listening for the status on your server, will be included)

Fried brain syndrom setting in, what else am I missing? Any ideas?








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

 

[vb5prgrmr]

TheTuna,

How about a companion program that you can shell anytime you want or at bootup of your program?

Here is the thought. Companion program when shelled downloads

http://www.someserver.com/somedirectory/Version.txt

and reads it into memory check current system against list (checks version/date/exists etc). If it finds updatable file (beyond main app) it will check file for source and download and save then to their correct directory/filename.

Now when it comes to the main app the companion program would download it to a temp directory. Once it had it, it would then check to see if main app is busy (details need to be worked out), and if not it would kill main app, copy over and restart it. Thus its job being complete it would then kill itself until it is called upon again.

Would something like that do?

Good Luck

 

[TheTuna]

Right, that's the basic idea, 5... The "companion" receives the script, processes and performs the tasks... or am I following you correctly? No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[mattKnight]

Hey Tuna,

I've been thinking about this for a LAN app iam looking at, I came to the conclusion that it is easier to poll an update from the client rather than push it out.

I was thinking of something like this, (with a client)
start up MyApp.exe (Main system)
initiate activeX component for updater
Depending on result from ActiveX, close app and start script to restart MyApp.exe

inside activeX
check lastupdate date from local registry
check UpdateIssued date on remote server
if different, pull down updates from specified directory
unzip, and register if required.
if MyApp.exe needs update create a restart script return
value to MyApp.exe


But if your system is unattended, maybe this activex could be instanced from a W2K service or maybe less robustly from the task scheduler.

And finally, is there any advantage in using some sort of file version table locally and remotely to govern the upgrade?

Just my thoughts


Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[vb5prgrmr]

Yes, that is correct.

Good Luck

 

[TheTuna]

5, you threw me off a little bit, because I was thinking you meant a companion to the auto-update program I was referring to... I was way too sleepy to be working on that last night.

Matt, agree, the client-side will actually do the polling, but when an update is required, the client will first receive a script, then parse and perform the tasks. You've got some good ideas, and I appreciate your input.

I just received mucho changes for the kiosk software that I have to get done tonight, so I have to put the update project on the back burner for tonite.

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

 

[skiflyer]

Intriguing thread, I just finished writing an auto-updater for my company... rather than invading the app, I used a bootstrap for it... sounds like you're considering something similar, but separate from your program.

Anyway, some things you might want to look into...

1) BITS, if you're concerned at all about bandwidth, just use what's available!

2) This website, it unfortunately didn't help me much because of certain issues ... but it was interesting reading, and may get your mind going in the right way.

http://www.msdn.microsoft.com/msdnmag/issues/03/02/BITS/default.aspx

3) Rollbacks, sometimes updates go bad.

4) Logging, so you always know who has what.

-Rob

 

[bennynye]

I am looking to do something simillarl internaly here. I posted a simple SOAP qestion earlier today, but the goal of the app is to do the following without a database.

1. Initial App launches secondary Update App.
2. Initial App sends Update App the following (DDE):
Location on localmachine
App name
App Version
3. Initial App Kills itself
4. Update App sends SOAP request to Server with the App Version.
5. ASP on server responds reads request and compares to XML on Server that contains a list of apps and the dll's and ocx's that are needed for each update, As well as their locations on the server.
6. Update App copies the files to the client machine.
7. Update App launches Modified Initial App.
8. Update App Kills itself.

This seems like a pretty strait forward way of handling updates, but I may be wrong.

 

[TheTuna]

Again, thanks for the colaborative details... more to come. When everything starts to get nailed down, I'll publish a complete outline.

I considered roll-backs, and I want it, but for the sake of getting this thing done in time, I decided to leave that out, unless I can get someone to chip in and write that part.

I still think we'll all benefit from this, since it's my plan to make this a stand alone program that doesn't care what it's updating...

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

 

[TheTuna]

More on Roll Backs...

Before I deploy an update, I will be testing my script on a test machine... all my kiosks are identical, lucky me, but in the "really real world", that's quite rare.

It's easy enough to backup files and keep a log of what took place, so reversing couldn't be too hard.

Seems to me I found a great place to utilize the all powerful, all knowing BlockInput API call... I'm adding in the option to block the keyboard and mouse to prevent tampering. Input blocking must be handled with care though...

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

 

[TheTuna]

It's time I do this: No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[petermeachem]

I'd be very interested in joining in here. I recently tried all the commercially available solutions I could find. Most were either severely limited, just plain didn't work, or the update file was much the same size as the original install programme. I got round the original requirement but I could still do with something for myself.

I would encourage simplicity. I far prefer something simple that works rather than something very clever and complex that doesn't.

We do go some way towards this now. We can send a script that runs updates to the programme database, changes ini files, installs fonts etc.

http://www.therockalltimes.co.uk/

http://english2american.com/

 

[TheTuna]

everyone's input is welcome, and I agree 100% that simplicity is paramount... excellent point.

I Realize that packages can get large though, which is why I'm going to implement zip compression. At present, my executable alone (for my kiosks) is close to 8 megs. Using normal zip compression, it shrinks to less than 300k. I'm happy with that. Although I do admit that I've got imbedded graphics that I plan to strip out, those graphics (jpg's and bmp's) still must be included.

Thanks for the input, keep it flowing in. No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!

 

[skiflyer]

bennynye,

I found bringing the XML from the server to the client to be the way to go, rather than bringing the version info up from the client to the server... either one is completely feasible of course.

TheTuna,
Keep us updated!

-Rob

 

[DonQuichote]

This URL might help in transferring smaller executables:

http://upx.sourceforge.net/

I use it with almost all my VB programs and I never encountered any problems.

Best regards

 

[bennynye]

skiflyer -

I'm curious how that would work. I think I brainwashed myself into thinking that I had to send up the current version to the server. Your way does seem like it would be a little easier.

Thanks for the response.

 

[vb5prgrmr]

TheTuna,

You could do most of this with the XMLHttp and ADO objects.

Good Luck

 

[TheTuna]

vb5: I don't have even 10 seconds worth of experience with XML... I'll be going with what I know, for sure!

As for client or server initiating the update, it could go either way, since they are both an integral part of it all.

First off, the update CLIENT will poll for updates by checking in with the server on regular intervals. Here's why... the clients are not on static IP addresses, and getting word to the client that a change is required would be a pain.

Administrator sets up and tests the update script.

Once the script is verified, the script is 'posted' where the client can find it.

Then the client will get word from the server (when the client checks in) that a package is available.

The client downloads the package (including the script) and executes the scripts instructions. During the update, the update will write a log entry for each scripted piece.

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).

The update script can also set the interval that the client checks in on.

Understanding that not every server in the world is on a static IP address gives the need for an alternate method of kicking off an update.

The update client can be instructed to monitor a specific URL for an update package. If a new package arrives, it should then download that package and proceed. Yet again, this could leave a gap... there must be a semi-permanent location for the client to monitor.

The good news is, the CLIENT has to be responsible for itself, instead of the server being responsible for hundreds or even thousands of clients. One action on the server takes care of unlimited clients.

Can anybody think of a way around the absence of static IP address? No Dolphins were harmed in the posting of this message... Dolphin Friendly Tuna!