We understand wanting to share your accomplishments of finding solutions to course materials. We ask that you make this repository private so that we can maintain the high caliber of learning and protect the value of the degree. When students and employers find that course solutions are easily found, it can raise concerns if the material is really being learned. We have found students who have copied portions of code they found from GitHub and submitted it as their own work. By making the repository private, we can ensure that current students are unable to use your work as their own. We understand that employers like to review students' code, so an option is to share the code by inviting them to the private repository.

Project README file

This is YOUR Readme file.

Project Description

Please see Readme.md for the rubric we use for evaluating your submission.

We will manually review your file looking for:

• A summary description of your project design. If you wish to use grapics, please simply use a URL to point to a JPG or PNG file that we can review

• Any additional observations that you have about what you've done. Examples:

  • What created problems for you?
  • What tests would you have added to the test suite?
  • If you were going to do this project again, how would you improve it?
  • If you didn't think something was clear in the documentation, what would you write instead?

Known Bugs/Issues/Limitations

Please tell us what you know doesn't work in this submission

References

Please include references to any external materials that you used in your project

Provide Following Functionality

• Whole-file caching. The client should cache whole files on the client-side (i.e., do not concern yourself with partial file caches). Read and write operations should be applied to local files and only update the server when a file has been modified or created on the client.

• One Creator/Writer per File (i.e., writer locks). Clients should request a file write lock from the server before pushing. If they are not able to obtain a lock, the attempt should fail. The server should keep track of which client holds a lock to a particular file, then release that lock after the client has successfully stored a file to the server.

• Client initiated Deletions. Deletion requests should come from a client, but be broadcast to other clients attached to the server. In other words, if Client1 deletes a file locally, it should send a deletion request to the server as well. The server should then delete it from its own cache and then notify all clients that the file has been deleted.

• Synchronized Clients and Server. For the purposes of this project, you'll need to ensure that the folders for the server and all clients stay in sync. In other words, the server's storage and all of the clients' mount storage directories should be equal.

• CRC Checksums. To determine if a file has changed between the server and the client, you may use a CRC checksum function we have provided for you. Any differences in the checksums between the server and the client constitute a change. The CRC function requires a file path and a table that we’ve already set up for you. The return value will be a uint32_t value that you can use in your gRPC message types. CRC32 is not perfect, but for the purposes of this assignment it will suffice. An example of how to obtain the checksum follows:

std::uint32_t crc = file_checksum(filepath, this->crc_table);

• Date based Sequences. If a file has changed between the server and the client, then the last modified timestamp should win. In other words, if the server has a more recent timestamp, then the client should fetch it from the server. If the client has a more recent timestamp, then the client should store it on the server. If there is no change in the modified time for a file, the client should do nothing. Keep in mind, when storing data, you must first request a write lock as described earlier.

Implemente Following Operations.

• Fetch a file from a remote server and transfer its contents via gRPC

• Store a file to a remote server and transfer its data via gRPC

• List all files on the remote server:

  • For this assignment, the server is only required to contain files in a single directory; it is not necessary to manage nested directories.
  • The file listing should include the file name and the modified time (mtime) of the file data in seconds from the epoch.

• Get the following attributes for a file on the remote server:

  • Size
  • Modified Time
  • Creation Time

The client should be able to request each of the operations described above for binary and text-based files. The server will respond to those requests using the gRPC service methods you specify in your proto buffer definition file.