- Learn how gRPC works in [Introduction to gRPC](https://grpc.io/docs/what-is-grpc/introduction/) and [Core concepts](https://grpc.io/docs/what-is-grpc/core-concepts/).
- Work through the [Basics tutorial](https://grpc.io/docs/languages/go/basics/).
- Explore the [API reference](https://grpc.io/docs/languages/go/api).
## Big Picture
There are essentially two parts to this project, both of which that rely on using
gRPCs.
The first part is taking your simple blob store and splitting it to a distinct
blob *store* in `p2/blobstore/main.go` and command-line tool `p2/tool/main.go`. The *blobstore* is the only
part of this project that interacts with the file system and should be oblivious to the contents of the
blobs it is storing.
The second part is building a lock server that will take an *acquire* request for a file
path and acquire read (SHARED) locks on the entire path from the root down to the path's
tail, except that the very last might be a write (EXCLUSIVE) lock, depending on the mode
requested by the gRPC. For example, an incoming acquire (EXCLUSIVE) request for `/foo/bar.go` would
result in a shared lock of `/`, a shared lock on `/foo`, and then an exclusive lock on
`/foo/bar.go`.
Each of these locks should be implemented with `sync.RWMutex`, and acquire requests for
paths already locked with incompatible modes would result in the gRPC request being blocked
until the situation changes.
## Details
-`pbc/comm.proto` defines the object services that your servers will respond
to. The starter files contain files `tool/main.go` for talking to the
blobserver, and `app.go` to exercise your lock server and show how an application could
use the interface.
- The lock gRPC calls are made directly from the application level (see `app.go`)
## Setup
Download the starter files for this project [here](https://sedna.cs.umd.edu/818/projects/p2.tgz).
## Command-line parameters
```
go run cli.go [-d|-s <host:port>] (desc <sig>|get <sig> <destination>|put <source>|list|lock <path>|unlock <path>)
go run store.go [-d|-s <host:port>]
```
## Testing
There are several moving parts here, though you won't be writing all that much code. *Test
parts separately* when possible:
-`blobget.go` will use the same gRPC definitions to interact with your blobserver as
your main fuse program. Use it list the contents of the database and to debug your gRPC
code.
-`app.go` will use the same gRPC definitions as your lock server. I will be using it to
test your lockserver; you should too.
## Notes
- Use the `context` to set RPC timeouts to 60 seconds.
## Grading
I will assign grades vaguely as follow:
- 50 pts - blobserver
-`redis` test
- examine contents of leveldb and server workings w/ `blobget.go`
- 50 pts - lockserver
- I'll pass it various paths and verify that the correct locks are acquired, that gRPCs
are blocked until conditions are appropriate, and releases are correct. A release from
replica *i* should not unblock a lock held only by repica *j*.
## Files
This repository
contains the following files:
-`main.go` - Scaffolding for P3, which references files in subdirs `dfs`, `pbc`, and `pbl`.
-`blobget.go` - retrieves data corresponding to specific signature, name (such as
'head'), or pathname from your blobserver. Can also be used to print out all keys in the object store.
-`app.go` tester for your lockserver.
-`blob/pbc.proto` - definition of protobuf formats and services for blobserver
-`lock/pbl.proto` - definition of protobuf formats and services for lockserver
## Submit
Submit as follows (substituting your *real* directoryid for `<your dirid>`):
```
cd ~/go/src/818fall18/
tar cvfz p3.tgz p3
```
and upload to [myelms](https://myelms.umd.edu/courses/1247011/assignments/4738791).
