1 / 15

CS244B: Replicated Files Project Session

CS244B: Replicated Files Project Session. Anthony Ho. CS244B Administration. Graded midterms will be returned first Mazewar grading completed afterwards Chapter 6 out. Two new papers. ReplFs Overview. Develop a client file API that creates copies of the file on multiple servers.

kirra
Download Presentation

CS244B: Replicated Files Project Session

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS244B: Replicated Files Project Session Anthony Ho

  2. CS244B Administration • Graded midterms will be returned first • Mazewar grading completed afterwards • Chapter 6 out. Two new papers

  3. ReplFs Overview • Develop a client file API that creates copies of the file on multiple servers. • Appears to the application to be accessing one file, but replicated across servers. • Design protocol. • Everything due Thursday, May 29.

  4. Library Linkage • Use C/C++. • Run a sample application. You won’t get more than 128 writes.

  5. Interfaces • int InitReplFs(int portNum,int packetLoss); • int AddServer(char *id); Use this form • int OpenFile(char *name); • int WriteBlock(int fd, void *buffer, int byteOffset, int blockSize);

  6. Interfaces • int Commit(int fd); • void Abort(int fd); • int CloseFile(int fd);

  7. Writes • Writes using the client interface only permanently written to the file after the Commit function is called successfully. • If you Abort is called, then all writes since the last commit must be discarded

  8. Use transactions • Each transaction has an identifier • Composed of a sequence of changes • Atomic - All changes made or all fail • Commit, Rollback • Example: • Write(‘hello’, 0, 5) • Write(‘ world’, 5, 6)

  9. Two-phase commit • Client sends prepare to commit • Servers respond with ready to commit • Client sends out a commit • Once a server responds that it was ready to commit, then it must always be able to commit. Even if some messages are lost.

  10. Designing Protocol • Client may need to retransmit • Flow control to prevent packet loss. Sending many messages at once can cause congestion. • What if a server is disconnected or crashes. Should work if server is still up. Commit only if all servers read to commit. • Server might need to indicate which writes are missing

  11. Designing Protocol 2 • What do you do when aborts or commits are missed. • When does a new transaction start • Messages sent when • Closing a file • Aborting transaction • Other functions that you may use

  12. Implementation • Make sure packetloss parameter works correctly. Only needs to drop packets at the client. • Should not hang, crash, or produce incorrect files • We may use more than 3 servers.

  13. Implementation 2 • Handle errors. • System call errors. • Parameter checking. • API return values • Etc. • Use a checksum

  14. Other cases • Do not need to resync with crashed server. For example, the server crashes after multiple commits. Should work if server is up though. • All servers specified by AddServer from the user application. • Don’t need to worry about client crashing.

  15. Submission • Client code • Server code • Makefile that compiles code and creates linkable library • Protocol design, evaluation, and future directions

More Related