Team CMD Distributed Systems Team Report 2 1/17/07

1. C:\>members Corey Andalora Mike Adams Darren Stanley Team CMD Distributed Systems Team Report 21/17/07

2. Paper 1 File Consistency • “Achieving Strong Consistency in a Distributed File System” • Peter Triantafillou and Carl Neilson • IEEE Transactions on Software Engineering, Vol. 23, No. 1 (pp. 35-55) • January 1997 • http://doi.ieeecomputersociety.org/10.1109/32.581328

3. Paper 1 General Ideas • Motivation • Increase the availability of files • Increase performance in a DFS • Handle Failures • Server disk failure • Communication lost • Client failure

4. Important Terms • File Session • Sequence of system calls from open to close • Write-Sharing • Concurrent file access in conflicting modes • Availability • The ability of a client to access a file • Serializabililty • Series of concurrent executing actions on a file is equivalent to serial execution • File Caching • File data is stored in memory for quick retrieval and updates are propagated to servers

5. Consistency Protocols • Echo – Primary-site protocol • Harp – Primary-copy server protocol • Deceit – Decentralized protocol • Coda – Local copy editing

6. Deceit • Uses write-tokens to control file replication. • Server must acquire write-tokens in order for clients to write to files. • When acquired all other servers hold unstable versions. • The token holder updates its file, tells all unstable versions to update, and waits for a response back. • If all servers with the file respond, the token holder broadcasts a stability notice to update files to stable. • Reads are always allowed on stable copies. If not stable, request is forwarded to the token holder.

7. Protocol In Paper • Three main entities • Servers (provide services) • Clients (use services) • Agents (process client requests) • Sessions • Contacts (file server) • Agreements (between contact and agent) • State Information • Which servers have a current copy of a file • What agreements exist for a file • The status of in-progress updates

8. Open Operation (Fig. 4) • Agent, A1, chooses server, S1, that is to be the contact. • S1 notifies a majority of the servers of the open request • All notified servers return their file state to S1 • S1 determines the current state of the file • S1 notifies any contacts with conflicting agreements that were not notified in step 2 • S1 acquires a current copy of the file, if its copy is stale • S1 returns the results of the open() to the agent and if the open() failed, tells the other servers of the failure

9. Close Operation (Fig. 6) • The client requests a close, and the agent sends any cached updates back to the contact. • The contact accepts the updates, and returns the call to the agent. • The contact propagates any updates to some, or all, of the other servers.

10. What we can use • Use tokens to lock files • Must obtain token to write to file • Propagate updates when token is released • Mark files as unstable while token is in use

11. Paper 2 File Comparison 2. V. Henson and R. Henderson. Guidelines for Using Compare-by-Hash. Forthcoming, 2005. http://infohost.nmt.edu/~val/review/hash2.html

12. Paper 2 General Ideas • Comparing file content by hash should be considered carefully. • Hash collisions can occur although unlikely. • Collisions made more likely by non-random files. • Computationally intensive hash computation vs. network heavy direct file comparison. • If using hash functions for security no performance is lost. • Cryptographic hash functions are short lived.

13. General ideas continued • If collision occurs we are unaware • Alternatives - Compare whole file - Maintain state information about files.

14. Guidelines • Compare-by-hash should provide some benefit. Save time, bandwidth, etc. • System should be usable if hash collisions can be generated at will. • The hashes should be able to regenerate with a different algorithm at any time.

15. Our Application • Save network usage. Provides faster file comparison, especially on slow or congested networks. • False information may be received during read if collisions can be created at will. • The hash algorithm is abstracted and can be easily replaced with a newer, more robust algorithm.

16. What we can use • Use compare-by-hash and accept possible errors. • Represent all files with same hash as single file. • When accessing cached files, check if it is up to date by comparing hash. • Check hash values for security.

17. Paper 3 Security 3. “Strong Security for Distributed File Systems” • Ethan Miller, Darrell Long, William Freeman, and Benjamin Reed • Performance, Computing, and Communications (pp. 34-40) • April 2001

18. Paper 3 General Ideas • Use cryptography at multiple levels • To protect data • Hash data on both client and server • To be sure you're reading and writing what you wanted to • Encrypt files + file hashes together • ensures nobody can change the data without you knowing • Transparency • the user should have no idea the system is in place

19. Filesystem objects • Certificate Objects • contains information about each user, as well as the public key, and HMAC key • File Objects • Contains file meta-data information • Key Objects • Pairs a user with an encrypted key and permissions for a file or groups of files. • Data Objects • Contains the actual data of the file.

20. Operations Operation Read Write host server host server En/Decrypt yes no yes no Hash yes no yes no Signatureno no yes no Verification yes no no yes

21. What we can use • We don't need something as fancy as the paper provides, but we can use some of its key points • Hashing on the client side to verify data • Encryption of communication between client/server • Modified file system objects for efficient storage overhead

22. Hashing Consistency F3 333 W F2 X2 F1: {Client0 (token), Client3} F2: {Client5, Client6, Client7} F3: {Client1, Client5} F4: {Client4 (token)} F1 111 1 2 0 222 222 F1 111 7 Security F2 222 3 6 4 X2 222 5 F4 444 abc F2 222 F3 333 W Tying It All Together