Software Distribution Platform: Difference between revisions
Jump to navigation
Jump to search
(restructured) |
m (+code source) |
||
Line 24: | Line 24: | ||
* if newer version is available, fetch it (e.g. over existing TFTP) |
* if newer version is available, fetch it (e.g. over existing TFTP) |
||
* infection based distribution mechanism |
* infection based distribution mechanism |
||
** obtail code from neighbour |
|||
** new version can be injected on any connected node |
** new version can be injected on any connected node |
||
** distributed step by step to each connected node |
** distributed step by step to each connected node |
Revision as of 20:57, 17 November 2004
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
- obtail 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 UDP port 123) with neighbours
- guaranteeing similar system times
- 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