... | ... | @@ -160,7 +160,7 @@ complete the labs individually. |
|
|
Do a `git pull` to get the latest lab software. The skeleton code and tests for
|
|
|
this lab are in `src/viewservice` and `src/pbservice`.
|
|
|
|
|
|
```sh
|
|
|
```bash
|
|
|
$ cd $GOPATH/src/viewservice
|
|
|
$ go test
|
|
|
2012/12/28 14:51:47 method Kill has wrong number of ins: 1
|
... | ... | @@ -210,15 +210,15 @@ Each key/value server should send a `Ping` RPC once per `PingInterval` (see |
|
|
description of the current view. A `Ping` lets the view service know that the
|
|
|
key/value server is alive; informs the key/value server of the current view; and
|
|
|
informs the view service of the most recent view that the key/value server knows
|
|
|
about. If the viewservice doesn't receive a `Ping` from a server for `DeadPings
|
|
|
PingIntervals`, the viewservice should consider the server to be dead. When a
|
|
|
server re-starts after a crash, it should send one or more Pings with an
|
|
|
argument of zero to inform the view service that it crashed (of course,
|
|
|
about. If the viewservice doesn't receive a `Ping` from a server for
|
|
|
`DeadPings PingIntervals`, the viewservice should consider the server to be
|
|
|
dead. When a server re-starts after a crash, it should send one or more Pings
|
|
|
with an argument of zero to inform the view service that it crashed (of course,
|
|
|
`duplicate Ping(0)` calls will be interpreted as repeated crashes).
|
|
|
|
|
|
The view service can proceed to a new view in one of three cases:
|
|
|
1. it hasn't received a `Ping` from the primary or backup for `DeadPings
|
|
|
PingIntervals`
|
|
|
1. it hasn't received a `Ping` from the primary or backup for
|
|
|
`DeadPings PingIntervals`
|
|
|
|
|
|
2. the primary or backup crashed and restarted
|
|
|
|
... | ... | @@ -261,8 +261,8 @@ We provide you with a complete `client.go` and appropriate RPC definitions in |
|
|
`common.go`. Your job is to supply the needed code in `server.go`. When you're
|
|
|
done, you should pass all the viewservice tests:
|
|
|
|
|
|
```sh
|
|
|
$ cd ~/6.824/src/viewservice
|
|
|
```
|
|
|
$ cd $GOPATH/src/viewservice
|
|
|
$ go test
|
|
|
Test: First primary ...
|
|
|
... Passed
|
... | ... | @@ -406,7 +406,7 @@ forward the resulting value, which might be large. |
|
|
The skeleton code for the key/value servers is in `src/pbservice`. It uses your
|
|
|
viewservice, so you'll have to set up your `GOPATH` to point to the repo's root
|
|
|
directory.
|
|
|
```sh
|
|
|
```
|
|
|
$ cd $GOPATH/src/pbservice
|
|
|
$ go test
|
|
|
Single primary, no backup: --- FAIL: TestBasicFail (2.00 seconds)
|
... | ... | @@ -448,7 +448,7 @@ Here's a recommended plan of attack: |
|
|
|
|
|
You're done if you can pass all the pbservice tests:
|
|
|
|
|
|
```sh
|
|
|
```
|
|
|
$ cd $GOPATH/src/pbservice
|
|
|
$ go test
|
|
|
Test: Single primary, no backup ...
|
... | ... | @@ -533,8 +533,8 @@ following: |
|
|
* Your partner's name (if you had one)
|
|
|
* How many hours you each spent on the lab.
|
|
|
* A high-level description of your design.
|
|
|
* Run `make lab2.tar.gz` from the repo's root directory to build the file you
|
|
|
should turn in.
|
|
|
* Run `make lab2_${UWNETID}.tar.gz` from the repo's root directory to build the
|
|
|
file you should turn in.
|
|
|
* See [Submission Requirements][submission] for specific format requirements for
|
|
|
the file you will upload to the Catalyst dropbox
|
|
|
|
... | ... | |