Description

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
Part 1 – Building a RPC protocol service

To test this part, I just manually tested all the methods with a variety of files that I got off the web, created and from the sample files folder. For store I first tested a
small file to make it was storing it on the server correctly, then after that was determined to be true, I would store a larger file, for example thos jpg files from the sample files folder. I took the same approach for the fetch and delete methods. For the list methods, I had the list method on the client side print out the result that was given back from the server to determine that it was listing the correct files only and not any extra folders or anything. For the get status method, I would get the status of the method and then just compared the values of what was returned to actually properties of the file to make sure it matches.
Part 2 – Completing the Distributed File System

For part 2 of this project, we had to build and completely a very basic distributed file system or DFS. The main difference between this part and part 1 is that the rpc calls made in part 1 is synchronous, whereas for part 2 its asynchronous. This will allow the server to listen and communicate with whichever client is connected and made a change on their mount path. This is the mount command for this part. The client uses the handle callback method and inotify method to check if the mounted directory of the client has any changes. Depending on the change made, the respective rpc method will be called to the server from the service stub. The existing functions such as fetch, store, list, delete, and get status were all copied over from part 1. The main difference being that, all those functions were edited to be asynchronous, meaning mutex locks were added around the functions and only one client can access the file at a time. If the client is trying access the same file that another client has a lock on, they are denied access. The file can only be access when the client can get the lock. To determine whether not the client has the lock to the file, I used the std container map with a key value pair of the file name and the client id. The getwritelock function would check the file name that the client is requesting and check that the filename in the map points to the client id of the client. If it does, then the client already has the lock, if the filename exists in the map but points to a different client id, that means another client currently is accessing the file and thus access is denied. If the filename isn’t in the map, the filename and client id are added giving the client access to the lock. This check is done on all those file methods to prevent multiple clients trying to write to a file at the same time. In the callback, we had to do a variety of checks to determine which method gets called. If the client mount path doesn’t have the file, the fetch method is called to get it from the server. Otherwise if the server modified time is greater than the client modified time for the file, it fetches, and if its the vice versa condition, it stores the file from the client onto the server. For most of this project, I followed the design laid out by this diagram: https://github.gatech.edu/gios-spr21/pr4/blob/master/docs/part2-sequence.pdf.
I used two locks for the store and fetch methods so I could have one lock mainly lock the file it was actively using and the other lock would be put on the directory to prevent other clients from making major changes to the directory.
For this part, I took the same first approach as for part 1, as these methods should still work as expected and not be broken. Once those tests were completed I moved on to testing the writelock and making sure that functionality was working. Since I was only testing with one client, to fully test the get write lock method I would hardcode in some values in the server side method to add some key pair values to the map first so when the client makes a call, it would return Resource exhausted and exit. I did this testing method to test both the getwritelock wrapper around the store and fetch methods. To test mount, I would start out with all the files from sample files folder and move them into the client folder and then would do a variety of tests, such as moving them out, deleting them and so on. I also put in a text file on the client side and edited that file to make sure the client was updating the server with the updated version of the text file.
One problem ran into was the shared mutex and using it. At first I tried to use the shared_mutex, but it kept throwing me errors when I tried compiling the code, when I
Recommendations

In the test suite, I would’ve added more variety testing of the methods since this is an asynchronous service. Doing this will fully test the DFS and determine whether or not its working as expected. Maybe more edge cases such as a client trying to store the same file another client is trying to fetch from the server or a client trying to delete a file while another client is trying to store/fetch it at the same time.
I think for part 2, the documentation on how the mount command wasn’t very clear. Like I mentioned earlier, it wasn’t till I read a classmates piazza post that I got a good understanding of what the mount was doing and how to actually trigger those callbacks. The student’s response on that piazza post was very well documented that it was easy to read and understand at the same time.
References
I used this repo to get started with the SayHello RPC programs: https://github.com/grpc/grpc/tree/v1.35.0/examples/cpp/helloworld. Message buffers:
https://developers.google.com/protocol-buffers/docs/reference/google.protobuf. time utils from google: https://developers.google.com/protocolbuffers/docs/reference/cpp/google.protobuf.util.time_util. More RPC understanding: https://grpc.io/docs/languages/cpp/basics/. how to trigger callbacks: https://piazza.com/class/kjwcg2w7lw87li?cid=1571.