> For the complete documentation index, see [llms.txt](https://berkeley-cs162.gitbook.io/hw-6/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://berkeley-cs162.gitbook.io/hw-6/tcp/your-tasks/part-b.md).

# Part B

#### Retransmitted Messages

To begin part B, you will need to go back and add functionality that allows the 2PC follower to handle the cases where the 2PC follower gets a retransmission of a previously seen message. For example, if the follower gets two COMMIT or ABORT messages in a row. 

#### **2PC Crash Handling**

Now that you have the Leader and Follower 2PC implemented, you should be passing all the basic 2PC tests on the autograder as well as the End to End tests. Ideally, you also pass the retransmit tests as well. This is a good indicator that your internal state is correct -- something that is crucial to Part B. 

In Part B, you will implement the `replayJournal` function for both the Follower and the Leader. This function will iterate through the Journal and replay all the actions that have been committed to the journal. At the end, you should be able to continue receiving messages from where you left off in the Journal.

The journal can be read using an `EntryIterator` which as the functions `HasNext` and `Next`. The journal itself can be modified with the functions `Append` and `Empty`. You must implement journaling in the follower's `vote` and `global` functions. In the leader, you must implement journaling in `Put`. 

In both, you should implement the `replayJournal` function. For the follower, this function should update the internal state based on what entries were logged. For the leader, this function should either make a global COMMIT or ABORT based on what was last logged.

When implementing `replayJournal` for the leader, you may at one point need to pass a context to some helper functions. The context is a concept  in Golang that adds timeouts and deadlines to requests and you don't really need to understand how its used. (Although if you are curious this [video](https://www.youtube.com/watch?v=LSzR0VEraWw) is great.) The context normally comes from the gRPC `Put` call, but when replaying the journal we no longer have a context to work with. Thus we need to make a new context, which you can do with `context.Background()`.  

**gRPC Written Responses**

Create a text file called `hw6.txt` in the hw6 directory. In it, answer the following questions:

1. gRPC is a remote procedure call implementation by Google using the protocol buffer. In your own words, what is a protocol buffer? Feel free to use the internet to look up the answer.
2. gRPC protobufs are defined by a interface description language. You can see an example of this in `api/kv.proto` . Take a look a that file and describe what the keywords `service`, `rpc`, and `message` define.
3. The proto file is then compiled into an gRPC framework for the language of your choice. From a high level, how does a Golang program use the compiled gRPC framework? You can take a look at the `pkg/tpc/rpcserver.go` as well as the compiled frameworks in `api/kv.pb.go` and `pkg/rpc/tpc.pb.go`.
4. For the Two Phase Commit RPCs, the `pkg/rpc/tpc.proto` defines a service that implements an RPC which takes a stream and returns a stream. This RPC is called a bi-directional stream. How is the bi-directional stream different from a normal request-response RPC?
5. Take a look at the skeleton code for how the 2PC Leader sends messages to the followers and wait for responses located in `pkg/tpc/messagemanager.go`. Where is the bi-directional stream between the leader and each follower created? What does the function `SendMessage` do?
6.  How does its behavior of `SendMessage` change based on the value of the `retry` argument? To help answer this question, take a look at the helper function `sendSingleMessage`. In what situtaion would the retry argument be used?
7. `SendMessage` has different `retry` values for sending a vote request and sending a global command. Take a look at the `globalRequest` and `voteRequest` functions in `pkg/tpc/tpcleader.go`. Why does one have it set to true and the other have it set to false?