Software Distribution Platform: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
(NTP) |
||
Line 30: | Line 30: | ||
* sign each software update package with a CA key |
* sign each software update package with a CA key |
||
* CA public key is preinstalled with the base system on every node to check authenticity of new files |
* CA public key is preinstalled with the base system on every node to check authenticity of new files |
||
* synchronize system clocks over NTP (using UDP port 123) with neighbours |
* synchronize system clocks over NTP (using broadcast UDP port 123) or a simpler non-standard protocol with neighbours |
||
** guaranteeing similar system times |
** guaranteeing similar system times for software switches and logs |
||
* include software starting time (and end time for experimental software) in each update package |
* include software starting time (and end time for experimental software) in each update package |
||
* coordinated switch over to new version if system_time > start_time |
* coordinated switch over to new version if system_time > start_time |
Revision as of 06:21, 16 February 2005
Conception for a software distribution platform for a distributed network of WRT54GS nodes.
The identified requirements are as follows:
- dynamic network of homogenous nodes (no privileged nodes)
- nodes may be turned off or disconnected for any period of time from the remaining network
- network may be split for any period of time
- nodes may be added at any time
- no centralized datastore
- avoids single point of failure
- less administration
- robust and reliable updates
- allow updates even with broken routing
- cross-compatible beginning with version 1.0.0 (e.g. allow update of a node running 1.0.0 with version 1.5.99)
- broken, untrustworthy and malicious nodes must not be able to install unwanted software (optional: not interfere with the updating process)
- trustworthy developer team and CA
- all nodes should have the same software version running most of the time (ideally every second)
- implementation must fit into limited hardware (e.g. 32MB RAM + 8MB flash (optional: WRT54G))
The ideas to meet those requirements:
- discovery mechanism for newer versions on neighbours
- push and/or pull
- broadcast(push) and/or query
- if newer version is available, fetch it (e.g. over existing TFTP)
- infection based distribution mechanism
- obtain code from neighbour
- new version can be injected on any connected node
- distributed step by step to each connected node
- notification and update protocol never changes after 1.0.0 is released
- sign each software update package with a CA key
- CA public key is preinstalled with the base system on every node to check authenticity of new files
- synchronize system clocks over NTP (using broadcast UDP port 123) or a simpler non-standard protocol with neighbours
- guaranteeing similar system times for software switches and logs
- include software starting time (and end time for experimental software) in each update package
- coordinated switch over to new version if system_time > start_time
- coordinated switch-back to non-experimental version if system_time > end_time