Hi everybody,
My recent idea is to build (for the program I'm writing) an update system. here is a picture :

--------
| Server |
--------
|
| <------- Protocol1
|
--------
| Agent |
--------
|
| <------- Protocol2
|
----------------------------
| Client built in the |
| released program (RP) |
----------------------------

Description:

Server (Part of the update system)
Listening on a port defined in protocol1

Agent (Part of the update system)

- Program (dll or exe).
- Not directly related to the RP.
- Is distributed independentlyof the RP
- Undestand the protocol1 and protocol2
- Can be updated

Release Program (Only half Part of the update system)

- Program (exe)
- The one for which this system is build for.
- Have a protocol2 client builtin for :
* Binary package Update request
* Optionally source package request

Why ?

1) Personnal challenge
- Write the whole stuff needed using only FASM
- Learning network programming
- Security thought

2) I want my future distributed program to be able to request for new update.
All that will be left to the user is the authorization to install, no more need
for users to search throught the net for latest release of the program.

3) also source code could be delivered instantly and privately.

4) Protocol1 and protocol2 will define an authentication process.

Operating system target
-----------------------
Window XP (It's the version of window I'm currently working with)


What is your opinion ?

I find auto-update systems an interesting matter. They can be useful in many places, if designed well.
I can offer some help, if needed, but I'm under Gentoo Linux.

Why do you need a custom server? Why not have it based on HTTP + XML, like .NET's automatic updates?

My two cents:

No reboots. Ever. You should know how pleasant it is: "You've been upgraded to version XX.YY, now shut up and shutdown/reboot"

I would like some cryptography added too, some way the agent can check that the update really comes from the official server and not from a spoofed one like http://www.thetechherald.com/article.php/200831/1598/Kaminsky-DNS-flaw-used-as-an-example-in-testing-of-Evilgrade and many other ways (especially on LAN environments). So update signing is one of the things that should be added IMHO.

As for protocol I recommend you to use HTTP all you can because it is the most widely allowed to use (e.g. a LAN inside an office could have HTTP port 80 access to the Internet only).

Best way to implement this is put the updates at the project website and just use HTTP GET method using sockets to download the stuff.

Maybe you could also use gzipped updates and use zlib to unpack.

Code signing is such a pain-in-the-arse for small to medium business so nobody really cares… MD5/SHA hash check will be sufficient (BTW, it's what code signing does ).

Sure, code signing uses hashes but there needs to be a way to securely deliver the hashes else the hash will just be spoofed also. A simple asymmetric key function can suffice, either RSA or preferably (because of the smaller keys) ECC.

What comrade, LocoDelAssembly and revolution said.

HTTP, XML definition files, and pubkey-crypto signing. The first two make things easier for both you and users, the second is to prevent against all the really nasty attacks you can face in today's brutal world.