Software Distribution Platform: Difference between revisions

From
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