CSE533: Computer Networks (Fall 2001) Course Project (ver. 27 Aug, 17:35) Scott Stoller ========== Due Dates Team formation: midnight, 4 September 2001 Mutex protocol [Chokler et al., Figure 1]: 4:00pm, 17 October 2001 Entire project: 4:00pm, 5 December 2001 ========== Grading 65% functionality, correctness, and efficiency of code 10% readability of code (modular design, meaningful variable names, etc.) 15% testing (quality of testcases and test.txt) 10% documentation (quality of comments in code, design.txt, instructions.txt) ========== Teams The project is designed to be done in teams of three students. Before the team formation deadline, one member of each team should send a message to stoller@cs.sunysb.edu containing the names and email addresses of the team members. I will pseudo-randomly create teams from the set of students who do not find teams on their own before the deadline. ========== Programming Environment You are expected to use Java. If you believe there are good reasons to use a different programming language, feel free to discuss the reasons with me; if your reasons are convincing, I will approve your use of a different language. You may use any Java development environment that supports JSSE (Java Secure Socket Extension). JSSE implementation, documentation, and examples are at http://java.sun.com/products/jsse/ . On the CS Dept Suns, JSSE is installed in /usr/local/pkg/jsse/ . Some local info is available at http://www.cs.sunysb.edu/faq/docs/jsse.html . Note that you need to add the following entries to your CLASSPATH /usr/local/pkg/jsse/lib/jcert.jar /usr/local/pkg/jsse/lib/jnet.jar /usr/local/pkg/jsse/lib/jsse.jar If you have a PC, it should be straightforward to download JDK1.3 (or JDK1.4beta, if you're adventurous) from www.javsoft.com and JSSE and install them under Linux or Windows. If you prefer a visual integrated development environment, you can take advantage of the CS Dept.'s license for Borland JBuilder5. JBuilder5 CDs will be available from someone; stay tuned for details. ========== Replication Protocol Fault-tolerance and security are achieved by replicating the state of the service at multiple servers, and ensuring that the service is available even if a limited number of servers crash or are corrupted by a malicious attack. The replication protocol is described in G. Chokler, D. Malkhi and M. Reiter. Backoff Protocols for Distributed Mutual Exclusion and Ordering. In Proceedings of the 21st International Conference on Distributed Computing Systems (ICDCS), IEEE Computer Society Press, 2001. Available from the course web page. The protocol requires authenticated channels. These should be implemented using JSSE. Interfaces should be used to separate the replication protocol from the service to be replicated. It is good style to put all of the classes that constitute a service into a package. Sample code with this structure is available from the course web page. A major design decision is whether to use secure sockets directly or use RMI over secure sockets. RMI is higher-level and therefore generally preferable, but I do not see a convenient way to achieve the authentication needed for this project using RMI over SSL. If you see a way, write a detailed design, describing how servers securely determine which client initiated each incoming remote invocation, and how clients securely determine which server possesses each remote object that it uses (note that rmiregistry is not intrinsically secure); don't forget to describe the expected contents of the trust store and key store of each client and server. A correct, simple, and efficient design for this is worth a significant amount of extra credit, regardless of whether you implement it. Define classes corresponding to the kinds of messages used in the protocol, and use ObjectInputStream and ObjectOutputStream to send instances of these classes over the secure sockets. Clients should contact multiple servers concurrently, and servers should handle requests from multiple clients concurrently. Thus, clients and servers are multi-threaded and require appropriate internal synchronization. As always, avoid repeating code. For example, write a routine that invokes an operation on servers until it receives responses from a quorum, and use that routine to implement lines 11-13, 26-27, and 29-30 of the client pseudo-code in Fig. 2 and the similar section of pseudo-code in Fig. 1. IMPORTANT: Include comments in your code to indicate the correspondence between sections of Java code and sections of pseudo-code in the paper. Correctly understanding and faithfully implementing the replication protocol is an important part of this project. Of course, I would be happy to see improvements to the protocol. All changes/improvements must be described explicitly in your design document, together with the motivation for the change and an argument that the modified protocol satisfies the original requirements. Test your code as thoroughly as feasible. Testing requires code that acts as a client of the service, i.e., that invokes submit(o). Testing your system's correctness when some servers are compromised requires code that behaves as a compromised server. This "test harness" code typically involves random choices. Consequently, some mechanism (e.g., shell scripts) that automates repeated execution is desirable. ========== Secure Fault-Tolerant Storage Service This service should be implemented on top of the replication protocol. The interface is vaguely NFS-like. Data stored by the servers is divided into pieces that I'll call "files", even though the servers simply store the data in RAM, not on disk. For simplicity, clients always identify files by number (like an i-node number); no directory service is provided. The operations and brief descriptions of them appear in the sample code, in FileService/Service.java. Extra credit: Design and implement an access control mechanism, controlling which clients may access which files. Warning: Don't even think about the extra credit until all of the required functionality has been implemented, thoroughly tested, and debugged. If the basic functionality does not work, no extra credit will be given. ========== Demos During a demo, the team compiles its system, runs the system on some testcases, and answers questions about the design and the code. Near the project due dates, we will produce a list of times when the T.A. is available. Your team should sign up to hold a demo during one of those timeslots. Scheduling a demo is your responsibility. If your team does not do a demo, we will not be able to grade your work, causing your team's score to be zero. ========== Suggestions Use diagnostic messages to help yourself (and the grader) determine what's happening during execution of your program. For example, you might define class Log { public static void println(String s) { System.out.println(s); } } and use Log.println to print diagnostic messages. This way, it's easy to distinguish them from other print statements, and they can easily be redirected to a file, disabled, etc. You might want to write a slightly more elaborate version of Log that allows messages to be divided into categories and allows selected categories of messages to be enabled. ========== What to Submit All project submissions (i.e., mutex protocol and entire project) must include: 1. code, including code used for testing 2. instructions.txt describing how to compile, configure, and run your system. 3. design.txt describing all interesting issues and decisions that arose during the design and implementation. 4. test.txt describing the tests that were done and their outcomes. 5. contributions.txt describing the contributions of each team member (at least one paragraph for each team member). Don't forget to read "How to Submit an Assignment" on the course web page!