Designing and building a fault-tolerant cloud file system with file locking and cryptographic security (medium)
Learn about the RESTful or WCF (Windows communication foundation) approach to building a service and decide which of these will be easiest for you (on Linux, REST is usually easiest; on Windows, WCF is easier, if you use Visual Studio for development). Without using Vsync at all, design a file server that offers the standard file system operations: open, read, write, seek, close, stat, etc. The data should be stored on the file system local to the servers. Test your code.

Now modify it by replicating the server (see the remarks above, in connection with the directory service). Add a file locking API. You'll be using Vsync to handle replication of the file I/O operations, and for file locking. Add a state transfer that can transfer files that have changed file a server was in the failed state, but that doesn't transfer files that haven't changed while the server was down. This will have you part way done: you'll now have a fault-tolerant solution.

Now think about options for securing your solution. Will the Vsync g.SetSecure() feature suffice, or do you need to do more in order to adequately secure a file system solution? How should your solution detect the user id of the person running the program that talks to your server? Would a person with some other id have a way to look at the bytes in a stored file, or would they need the proper ID to see the file, if they could log onto the machine where the server is running?

Inside the Vsync code you can find methods that Vsync itself uses for data encryption and decryption, using the group key from g.SetSecure(). Normally we don't make these public, but Isis2 is open source. By study of the code, figure out which methods you could use to secure your disk-based file data, and by calling the code from your file server logic, demonstrate that your solution works properly.

Last edited Nov 19, 2015 at 9:18 PM by birman, version 2