DVFS Design Document
	(Internal documentation)

DVFS is built using CMT for video play back as well as with the HORUS toolkit to ensure reliability. The interface to Horus used here is Tcl. A client may request video of this system and will be guaranteed reliable video within a finite period of time. The video will be provided by multiple sources (servers). These servers were previously clients to the DVFS and currently hold some of the needed frames in their cache optimally, they should be located fairly close to client making the request. This is NOT transparent to the client.

System Entities/Concepts

Coordinator (coord)

The module in charge of all the Horus/reliable broadcasting, strategy development for requests in a given domain. Monitors the state of the system in that domain, recuperates from failure. Currently the system has 2 coordinators, Primary and Backup, the addre of which are hardwired. The Backup reflects the primary's state and becomes primary should Primary crash.

Coordinator's Tasks

Receives client request and processes it.
Develops a strategy (i.e. defines which servers as well as the mask of the video they should send to the client) to meet client request
Updates sytem with new servers and their cache content

Server

The Server provides the client using CMT with a striped (bit mask) version of the video requested.

Client

Clients make requests and receive the requested video reliably. They then may become servers capable of providing another client with what is in their cache.

Domain

A group of server's controlled/monitored by a coordinator. Corresponds to a LAN. Approximatetly 200 servers/clients

Data array

Stores all the servers, their addresses, the video and frames they have in their cache. Used to develop a strategy.

Horus Groups

Coordgrp

One coordinator group. Horus process group comprised of the coordinators

dgrp

A domain group. Horus process group comprised of the coordinators, the servers and clients currently being served.

vgrp

A video group. Vgrps form and dissolve, one for each request being served. Each group consists of the coordinators, the client, and the servers fullfilling the clients request.

Trace of action incited by Client request

Both the primary and the backup receive the client request. They place the request on a list of pending request that do not yet have strategy.

The primary calls the strategy module within the coordinator to define a strategy to fullfill the client's request. It places this strategy on a list of strategies that are currently being serviced and removes the corresponding request from list of pending requests. The backup reflects all these changes.

The primary notifies the client to join the domain group

The primary broadcasts to the domain group a list of server addresses, their corresponding masks and the videogroup number they are supposed to join (i.e., the request they are supposed to service).
Note: the variable "im" in the code corresponds to is set to 1 if the server should start sending frames immediately, set to 0 if the server should just standby as potential backup. Currently the code assumes that 4 servers begin sending frames immediately, 2 are backups.

Once the client is finished viewing the video, it contacts the coordinator (broadcast to primary and backup) to inform them that it is done and lets them know what frames it has in its cache.

The primary calls VPDONE, calling all members of this video group to leave, disolving video group and updating lists. The primary processes the client data (Update $clientdata), and suggests the client keep a certain set of frames based on the current system configuration. The primary thus updates the Data array.

The client is now a server unless he has not managed to keep any frames in his cache. If the later is the case, he is asked to leave the domain.

Trace of action on crashes

Case 1: Primary Crashes

Backup becomes primary and sets up new backup via Tcl-DP conection.
Note: log layer ensures that this new endpoint becomes a member of all the groups the primary is member of. All state is transfered

Primary coordgrp cast all current lists to new backup.

Primary fulfills all request that have not been taken care of by developing strategies, implements these strategies and those that are pending, updates lists.

Case 2: Backup Crashes

Primary sets up new backup via tcl-dp connection

Primary coordgrp cast all current lists to new backup.

Continue as usual.

Case 3: Server in video group crashes

Primary coordinator sends message to video group for next backup server to start sending its frames.

Case 4: Client in video group crashes

Dissolve video group. Use CMT notification of client death to dissolve group.