Cient Video Request: Plan of Action
(1) Client joins the horus domain group (at a well-know group address) and casts a client request to the Coordinator:
SDJOIN $domain CRQ [list $movie_id $mask]
(2) Coordinator processes request by assigning the request a unique ID (RUID) and places it on a list of pending requests:
GETRUID PRQ [list $RUID $movie_id $mask]
(3) The Backup Coordinator simulates the Primary's actions only as far as keeping the same lists and joining the same groups. It needs to inherit any data arrays and lists in the event of a Primary failure.
(4) Coordinator defines a strategy for the RUID which basically consists of the following:
strategy: {RUID movie_id client_addr server1_addr mask1 . . .
. . . serverN_addr maskN}
set strategy [DSTRG [list $RUID $movie_id $mask]]
(5) Coordinator places the strategy on a strategy list, creates a new video group and joins it:
STRG $strategy
(6) Coordinator tells all servers and the client involved in the strategy to join the video group. Currently this is cast to the entire domain group instead of just those particular servers specified:
SVJOIN [list $vgrp_addr $vgrp_nbr $strategy]
(7) Client contacts first (4) Servers specified in the strategy and begins receiving video (hopefully). This is done through CMT and Tcl-DP.
__________________ | Server 1 | | MJPEGFile Object | __________ |__________________| \ \ ____________________ . \ | Client | . ---- | MJPEGWriter Object | . / |____________________| __________________ / | | Server N | __________/ __________|_________ | MJPEGFile Object | | Client | |__________________| | MJPEGPlay Object | |____________________|
(8) Once Client receives all its data, it tells the Coordinator and sends it a mask of all the frames it has cached:
CDONE [list $RUID $mask]
(9) The Coordinator dissolves the group by leaving it and telling all those involved to leave also:
Coordinator: VDONE [list $RUID $vgrp_nbr]
Servers: SDONE [list $RUID $vgrp_nbr]
(10) The Coordinator updates its data arrays/lists and the Client stays in the domain group.
NOTE: Crashes are automatically detected within a Horus Group by theVIEW upcall.
(1) If Primary crashes, the Backup becomes the Primary by inheriting all its lists and sets up a new Backup by telling one of the servers in the domain group to execute
[SETUP $domain]
-- Backup already has updated lists of dead Primary
-- Backup becomes New Primary
-- New Primary tells one of the servers in the domain to become a new Backup
-- New Primary casts all its lists to the New Backup
-- Things continue as before
(2) If Backup crashes, the Primary sets up a new one from the domain as it does in the above case
(3) If a Server in a Video Group crashes, the Coordinator replaces it with a backup defined in the strategy
(4) If the Client dies, stop. The Coordinator should notice the changed view and should call VPDONE or something like it.
(1) How the Coordinator should communicate the strategy to the Client
and Servers.
Need to send the masks (could be rather large). Should it use Tcl-DP or Horus
or something else.
(2) Currently, a Server or Client crashing is not taken care of. Need to look at group views and compare with current server lists to figure out which server actually died.
(3) How should a server crash be corrected:
Define a new strategy with new masks for all servers involved; or just replace the failed one with a backup but with the same mask
(4) Need to build the function DSTRG for the Coordinator. Alex is currently working on this.
(5) Need to create a CMT Writer object that accepts streams of frames from multiple servers and keeps track of the frames it has received (mask). That or just modify the MJPEGPlay object already in CMT.
(6) Still need to get CMT MJPEGFile objects to mask correctly (and
how to do it). We might be using a simple way at first (such as every 4 frames
starting at a certain index):
1: {frames: 10001000100010001 . . . }
2: {frames: 01000100010001000 . . . }
3: {frames: 00100010001000100 . . . }
4: {frames: 00010001000100010 . . . }
(7) CDONE needs to be implemented; i.e. the client needs to communicate back to the Coordinator its request ID and mask when done so that the Coordinator can call it quits for the video group and update its data array/lists.
(2) It would be nice to have a simple prototype supporting 4 servers to satisfy a client request by just before the break.
| DATE | GOAL |
| FEB 25: | Have a simple Strategist up and working |
| MAR 4: | Have crash cases working and CMT work done (masking and caching) |
| MAR 12: | Have Strategist working with list updating after clients send back their masks |
| MAR 23: | Be done with something that works satisfactorily |