[net2-wg] Summary of the latest changes in Deluge T2

[Razvan Musaloiu-E.]

Hi!

At the last net2 meeting Om asked me to write an email about what happened 
with Deluge in the last few weeks. Here it is.

The improvements started with the David "wizzardx" request of 4 things:
1) Improved stability of image dissemination.
2) Rollback gesture.
3) More image slots.
4) Information about the current running program.

I was able to implement the last 3 request with minimal changes. The fist 
request was not so easy because the lack of stability was mainly caused by 
lack of proper coordination between the various pieces that of Deluge T2. 
To make things clear let me briefly describe the way things are right now.

The two main parts of Deluge T2 are:
- TOSBoot, which is a straight port from T1
- DelugeC, which is the component that adds Deluge support to a regular 
application.

DelugeC in turn is made up of several parts:
- BlockStorageManager (new) and BlockStorageLock (new)
- FlashVolumeManager
- ObjectTransfer and DelugePageTransfer
- DelugeVolumeManager (new) and DelugeMetadata (changed)
- DelugeManager (new)
- DelugeP
- NetProg

The purpose of BlockStorageManager is responsible to virtualizing the 
BlockRead/BlockWrite for the volumes that holds Deluge images. The 
components that offers the services are called BlockReaderC and 
BlockWriterC. BlockStorageLock is a big lock which used to offer a 
Resource interface that allows the clients to get exclusive access to the 
volumes.

FlashVolumeManager is responsible for offering read/write/erase services 
over the serial port to some volumes. The component is using the 
BlockReaderC and BlockWriterC offered by BlockStorageManager. 
FlashVolumeManager is not used if the mote is not a basestation.

ObjectTransfer and DelugePageTransfer contains the main logic of 
dissemination from Deluge 2.

DelugeVolumeManager is implementing the erasing of an arbitrary Deluge 
image. This is a separate component because the operation is necessary in 
two places (DelugeC and DelugeManagerC) and is non-trivial because of the 
locking and way the access to the volume is done. DelugeMetadata is 
implementing a way to obtain the identification information about an 
image. Upon boot the component is also responsible for iterating over all 
images and deleting the ones that are not correct.

DelugeManager is responsible for implementing the -d (dissemination of an 
image) and -dr (dissemination plus reprogramming) commands. The commands 
are propagated to the rest of the nodes using the dissemination 
services offered by Drip.

DelugeP is responsible for implementing the -d and -dr received 
over the dissemination offered by Drip.

NetProg is responsible for rebooting the mote and writing the proper 
things in the internal flash in order to trigger a reprogramming by 
TOSBoot.

All the components followed by (new) are fresh. DelugeMetadata was changed 
in the sense that caching of the image metadata was replaced by a 
set of split phase operation. The reason for this was to avoid 
inconsistency.

One other change that is the one of the format of the binary image. The 
old format was following the Deluge 2 format which consists of 3 
parts: Metadata (16 bytes), CRCs (128*2 bytes), Ident (128 bytes) and 
data. The current format is merging the Metadata and Ident in one field so 
the format is like this: Ident (128 bytes) CRCs (128*2 bytes) and data. 
Another improvement is adopting the big-endian representation in all the 
multi-byte numbers.

One last change I made consists in merging the two structures used for 
storing the node ID and passing information to TOSBoot. The new one is 
call BootArgs.

Beside more testing other small things that I want to do are:
- renaming the DelugeMetadata to DelugeIdent in order to better reflect
   the current meaning.
- rename the imgNum to volumeId in several places.

I think this is all. I hope I didn't missed anything important.
Razvan ME