Winston Jodjana winj@uw.edu
Dixon Tirtayadi dixontir@uw.edu
Mengqi Chen franchen@uw.edu

Write-up
- A detailed description of your group's implementation
    client.py - The client file to send lock or unlock operations to a paxos node
    paxos.py -  The main node file that executes multi-instance Paxos
        paxos_utils.py - Misc. utilities used by paxos.py (e.g. ballot num)
        message.py - All the possible messages that can be sent between client and/to paxos nodes
        timers.py - All the required timers that help keep track of paxos nodes' states to make sure, for example, nodes aren't dead. 
                    Also have timers for timeout for assuming lost message
        lockmanager.py - File that handles all the lock and unlock operations specific to a client
    main.py - A utility file to spawn a paxos group with multiple nodes

    Our implementation make single node (paxos.py) serves all 3 roles of proposer, acceptor, and listener.
    Any node can accept a request from a client and it will be considered as part of the paxos. Any node is run separately
    on its own thread by running the main function of paxos.py on multiple terminal windows, for example. As such, a node
    can be easily killed to simulate node failure.

    There is going to be one leader that acts as distinguished proposer and learner. This is to ensure liveness as described
    in Paxos paper. We chose the first leader to be the first node in the paxos group. Subsequent leader will be done through
    a leader election by sending a election request (Uses first phase paxos) and exponential backoff to other nodes when the node 
    detect leader is failing. 

- Any assumptions you made
    Any subsequent request from client are treated as different operations (No at-most-once in server side)
    The identity of the Paxos group members are hardcoded
    No deadlocks

- How to compile, deploy and run your implementation
    Config file to indicate the addresses of the paxos group: config.json
    Spawn the paxos group based on the config file using:
        python3 main.py
    Start the client and send commands to a random paxos server based on the config file using:
        python3 client.py [client_host] [client_port]
        e.g. python3 client.py localhost 0
             lock 1
             lock 2
             unlock 1
             ...
             exit
        Note that lock can be acquired twice. One client sending lock 1 and lock 1 is ok, and only need single unlock 1 to be unlocked.

        Also, for every command done by the server. The LockManager will print the state of locks so you can see what is the state of Locking
        and check that it is consistent. For example: 
        "Current Locks: {2: ('0.0.0.0', 36086), 1: ('0.0.0.0', 53889)}" means that there are two locks currently acquired,
        Lock on value 2 held by client at ('0.0.0.0', 36086)
        Lock on value 1 held by client at ('0.0.0.0', 53889)

- Any issues or scenarios explicitly not considered
    At-most-once is not implemented in server side. It is possible for client to resend command and server executes it twice. 
    
- Any other behavior of the system you feel important to discuss (e.g. quirks, interesting behavior, performance characteristics, etc)
    Extra Implementation: 
    - Resending message. Use timeout for resending messages that may have been lost to keep Paxos going.