Outline

  /u/pierce/pub/629/handouts/project1

Later, this program will form the basis for some of our experiments with distributed programming. For the moment, we will deal with a non-distributed version that simply synchronizes different files on the same machine. Your job is to make several extensions to this program.

Running Java

1. We will be using Java version 1.1 for this assignment (and probably for the whole course)
2. To use the java compiler, make sure that your path contains the directory PATH=/l/jdk/bin:$PATH. For example, if you use bash as your shell, you can type

     export PATH=/l/jdk/bin:$PATH
   

   at the command prompt or, more permanently, add the line

     PATH=/l/jdk/bin:$PATH
   

   to the file .bashrc in your home directory.
3. Once your path is set, typing

     javac *.java
   

   will compile all the classes in all your .java source files and produce appropriate .class files containing executable bytecode.

   Typing

     make
   

   in the handout directory will have the same effect.
4. You can now run the synchronizer by typing

     java Snc file1 file2
   

   (where file1 and file2 are two files or directories to be synchronized) or just

     make demo
   

Assignment

1. The synchronizer can operate in several modes, which control what happens when an inconsistency is detected. One of these, the Ask mode, has been left unimplemented.

   Write the body of the class Ask. Your code should print the string explanation on the terminal and offer the user the options of

   1. executing atobThunk (you should print atobMesg to explain what will happen in this case),
   2. executing btoaThunk (print btoaMesg to explain what will happen in this case), or
   3. leaving this file unsynchronized.
   You will need to refer to the java api guide for information about how to do terminal I/O.

2. As it stands, the synchronizer is quite verbose, printing messages pretty much every time it does anything. When debugging new functionality, these messages may be useful; but we'd like to be able to turn them off.
   1. Write a new class Tracer (in a separate file Tracer.java) that allows this tracing information to be turned on and off dynamically. The Tracer class will not actually have any instances; instead, it should provide static methods tracingOn and tracingOff that control whether tracing information is printed, plus a static method println that can be used instead of System.out.println elsewhere in the program for printing tracing information.
   2. Fix the rest of the program to use Tracer.println as appropriate.
   3. Add a command-line switch to turn tracing on.

3. The method snc in class Snc uses the hash method of SncFile objects to compute cryptographic signatures of the two files, and then compares them to see whether the files are the same. (This will be useful later, since it will avoid transmitting the whole contents of the files across the network when comparing them.)

   The result type of hash is byte[] (array of bytes). Suppose we want to hide the fact that cryptographic signatures are represented as byte arrays.

   Define a new class Signature with a constructor that takes an object of class MD5 as argument and a method compare that takes another Signature and tests for equality.

   Make SncFile.hash return a Signature. Modify Snc.snc appropriately.

4. Extra credit: The present synchronizer may not choose the most efficient way of making two directories equal. In particular, if a file has been renamed on one side since the last synchronize, it will be deleted on the other side and re-created with the new name by copying. If the two directories were actually on different machines, this could lead to a lot of unnecessary network traffic.

   This is actually wrong: moving a file does not change its modification time, so in fact both files will be deleted (with no extra network traffic!). Thanks to Marat for pointing this out. For purposes of the exercise, you can assume that files will be touched every time they are moved.

   Extend the synchronization program so that it can recognize (some) situations in which files have been renamed and perform updates more efficiently (by renaming on the other side).

Questions

1. Watch the course newsgroup (ac.csci.b629) for announcements and discussion.
2. If you have questions that other people might find interesting, please post them to the newsgroup (and cc them to pierce@cs.indiana.edu, if you want a quick response from me).
3. Discussion and collaboration are encouraged. Please feel free to work on this assignment with other people, get help from wherever you want, etc. If a significant part of what you turn in is taken from someone else, please say so in the cover

Deliverables

1. A file README (or, if you prefer, README.html) containing a brief, but well polished, design document. This does not need to be long, but should just describe what you've done, concentrating on any novel extensions you've made.
2. Java source files (the parts you write should be well structured and documented)
3. A Makefile such that typing

     make demo
   

   will recompile files as necessary and then show your program doing something.

Submission Procedure

1. Place all the files for your finished project in a directory by themselves on a CS machine.
2. Make sure that this directory, all the files in it, and all enclosing directories are world-readable.
3. Send me an email whose subject line is "Project 1 submission" and whose body contains the pathname of this directory.
4. Your project will be considered as submitted at the time you send this email. Don't modify the contents of the directory any more after this.

Due date

I may possibly announce a postponement of this deadline if the project ends up taking many people more time than I expect. Watch the course news group.