_____________

				SECTION9

			      Irene Zhang
			     _____________


Table of Contents
_________________

1 Lab 4b architecture
.. 1.1 Client-side
.. 1.2 Server-side
.. 1.3 Moving configs


1 Lab 4b architecture
=====================

1.1 Client-side
~~~~~~~~~~~~~~~

  - key2shard maps Get and Put keys to a shard
  - shardmaster maps shards to replica groups
  - client side is already pretty much set up, but you have to implement
    at most once RPC yourself


1.2 Server-side
~~~~~~~~~~~~~~~

  - implement key-value store just like last lab with the Paxos log
  - tick() should check config from shardmaster occasionally
  - on new config, stop accepting requests for shards you lost and go
    get latest version of shards you gained (diff the new config with
    the old one)


1.3 Moving configs
~~~~~~~~~~~~~~~~~~

  - Be sure the move from one config to the next biggest one! What
    happens if you dont?
  - You don't have a leader, so all replicas may try to do a config
    change at once, You will probably want to coordinate this among the
    replicas in a group
  - You probably want to stop taking client requests during a config
    change. It depends on your design.
  - You need to make sure that when you move a shard from another group:
    (1) the group stops accepting requests for the shard at the same
    time and (2) the group is in the same config as you. So you either
    want to retry or start a thread to bring the group up to date
  - Think about what happens if the group is ahead of you in configs by
    a lot (what if the shard moved to you then back again?)
  - Locks are tricky. When one group calls another to move, if the
    second group has to move some shards from the first group, what
    happens? Make sure there are no deadlocks
  - Think about what happens if the move message fails. What should the
    RPC semantics for moving shards be?