02152 Concurrent Systems        Fall 2008
Mandatory Assignment 2: ITTP Server

Home

Plan

Material

Your are supposed to implement and document a simple Web server as specified in the document:

• Mandatory Assigment 2 Problem Description: ITTP Server (ps)(pdf)

Amendments, clarifications and FAQ are to be found at the

• update page for Mandatory Assignment 2

Information about practical matters is found below.

Observe that this assigment is fairly realistic and hence requires more coding than the first assigment including "plain" coding of string recognition etc.

Groups

The assignment is intended to be solved and reported in 30-35 hours each for a group of 2-3 (well-prepared) students.

You are expected to continue the group formation from the first assignment. If you would like to form new groups, you must inform HHLin due time.

Groups of 3 students are expected to make more elaborate solutions including at least one of the two extensions marked in the problem description:

• EXTENSION A    MD5 checksum generation, dynamic connection limit and server shutdown.
• EXTENSION B    Remote management.

Reporting

The general report requirements also apply to this assignment.

The main report text (not including appendices) is expected to be brief, about 7-10 pages. See further documentation hints below.

Each group must hand in one paper copy of the report no later than

Specific contributions by the individual group members should be stated, and the report must be signed by all participants.

Also, the program files for this assignment must be handed in electronically as well (also before the deadline). See details below.

Documentation hints

• Your report should be short and to-the-point. Aim to make the main report between 7 and 10 pages. Supplementary information, such as program listings, test results, user manual, detailed user interface design and so on, should be placed in appendices, as recommended in the general report requirements for the course.
• Since this task involves designing and implementing a moderately complex concurrent system, the report should contain information which makes it possible for the reader to understand the basic concurrency structure of the system. In other words, the answers to questions like:

  • Which threads are present and what do they do?
  • Where and how do they interact?
  • How are they synchronized?

  Since (at least) the second of these questions is difficult to explain in words, you are encouraged to use suitable diagrams.

• The main report should concentrate on giving a concise description of the system. This will typically cover topics such as:

  • Purpose: A very short description of the purpose which the system is intended to fulfil.
  • Specification: An elaboration of the requirements from which the implementation has been derived. You do not need to copy the entire content of the document describing the mandatory task; concentrate instead on describing how your solution restricts or extends the specification given in the document. If you found it necessary to ïnterpret" the instructions given in the document in some way, for example due to missing or unclear information, then this is the place to describe what you have done.
  • Analysis: An identification of the most challenging problems and outlines of solution alternatives.
  • Design: A description of important design decisions which have been made. (This will for example include the division of the activities of the server among threads.)
  • Implementation: A general description of the classes of objects used in the implementation including their responsibilities. Also non-trivial implementation issues may be described. More detailed descriptions of the classes, including class dependency diagrams, descriptions of the methods of the individual classes and so on, can be included in an appendix.
  • Test: The test strategy used, i.e. a description in general terms of how the server was tested. Detailed test programs (perhaps even a detailed description of a client used for test purposes), test schemata and test results should (at most) appear in an appendix. Do not forget to describe your approach to testing the concurrency aspects of your server.
  • Conclusion: Concluding remarks, covering such topics as how well your solution appears to work, and describing known major faults or areas for improvement.
• As stated above, you do not need to repeat large chunks of text from the description of the assignment in your report. Instead, make suitable references to the requirements given in the assignment.

Implementation hints

The Java API provides a number of classes which may be very useful to you in solving some of more syntactically oriented parts of this task. In addition to the java.net.Socket and java.net.ServerSocket classes referred to in [PMG] you may find it helpful to look at the descriptions of the classes:

Class	Uses
java.security.MessageDigest	Evaluation of message digests, such as MD5.
java.security.DigestInputStream	Automatic evaluation of digests for input streams
java.net.URI	Parsing and separation into components of URIs.
java.io.File	Setting and reading properties of files.
java.text.DateFormat	Parsing and formatting of date/times.
java.io.StreamTokenizer	Parsing of input streams into sequences of tokens.

 
Observe that your server must accept all requests that follow the given syntax, but you need not reject requests which are not syntactically perfect. For example, you may tolerate extra space between tokens or more general URIs. Since the protocol syntax is quite simple, a straight-forward, but systematic, parsing approach should suffice.

You are recommended to start with implementing a single method, e.g. GET, without consideration for header lines in order to get the basic functionality to work. Then you may add header lines, more methods, and management control.

The program will be tested with the Java SE 6 platform and you may use any class libraries within this. Other class libraries must be delivered with your solution.

Body representation

Both when reading requests and when generating responses, you should be very careful about the representation you use. You will probably like to treat header lines as strings. However, body content should not be converted to/from the String type, since that involves decoding/encoding which may change the length of the body as well as being dependent on the current locale settings. Rather body content should be read and written as raw octets (bytes).

 
There are various ways you may do this:

You may work only with (buffered) byte streams making any conversion to/from Strings explicitly yourself.
You may (for output) write to both an OutputStreamWriter as well as its underlying OutputStream.
You may consider using a DataInputStream for reading requests.

User interface

As stated in the problem description, you may design the management user interface as you like. Note, however, that an elaborate user interface is not appreciated if the basic functionality is not in order. Thus, you should give priority to functionality and usefulness rather than appearance.

Program parameters

For testing purposes, it must be possible to pass the port number, base directory, and user credential to your program as optional parameters. The parameters must be of the form:

• -port=<ITTP server port_no>
• -basedir=<base directory for paths>
• -userid=<user id>
• -passwd=<user passwd>

The default value of the server port should be 36000 and the default value of the basedir should be the user's current working directory (Java property user.dir). You may define the default values of the userid and password (for PUT) yourselves.

You may add other program options, parameters or Java properties if you like, e.g. if you are using RMI.

Packaging

Since this is a larger programming project, you are recommended to organize your code using the Java package notion. The toplevel package should be named ittp and the server could occur within that as ittp.server. If you have a separate control client program it may be named ittp.control. Otherwise you may organize your classes in subpackages as you like. Remember that in Java, the package structure must be reflected by the file structure.

Concurrent File Access

The presence of the PUT request raises the question whether the resources (files) should be protected against concurrent access.

For the given assignment, this issue is not central. First of all, you may assume that your server is the only OS-process accessing these files. With respect to the internal concurrency in your server, you may consider the following approaches depending on your level of ambition:

1. Ignore the problem of concurrent access to external files.
2. Write to a unique, temporary file and then rename it (see File class).
3. Implement an internal locking system within the server.
4. Use the file locking of java.nio

In all cases, the problem should be mentioned in the report.

Testing

For functional testing of the server, you will need a client, which can send both correct and incorrect ITTP requests to the server and collect up the responses. A starting point for such a client is given by the program TCP_Client.java. This will enable you to test out the server with several simultaneous clients, each running in a separate window, while the server management interface runs in yet another window. You may also study the program code to see how to make timeout on a connection. The client program may be modified as you like.

Initially, you are recommended to test your system with the server and all clients running on the same host, i.e. the one you are logged in on. If this works, you should also to try it out in a truly distributed system, with clients on different hosts and so on. Note that this may mean that you need to set up suitable permissions. The information on RMI in [PMG] and the page on RMI details should help you to find an appropriate setup in this respect.

Program Delivery

• Printouts of all the Java source .java files for the ITTP server (and possibly the control client) are to be included in the report as easily navigatable appendices.

  If you wish, you may also include source files which you have used for testing purposes.

• Files must also be handed in electronically for potential testing.

   
  Both the source files and the compiled .class files must be collected into one or more .jar files.

   
  If your source code and class files reside in the same tree structure, you may create a .jar file by going to the parent directory of the ittp package and issue the command:

  jar cMvf man2.jar ittp
   
  Otherwise, you may need to consult the manual pages for the jar command or let your IDE assemble your jar-files.

   
  If properly done, it should be possible to run the server out-of-the-jar by issuing a command like:

  java -cp man2.jar ittp.Server <options>
   
  Alternatively, you may use a manifest file to determine the server class making the jar-file executable.

   
  Optional clients may be included in the same file or given as separate jar-files.

  You are only requested to hand in the program for the server and possibly the control client, but if you wish to hand in auxiliary programs you may include these in the .jar file(s). You should then explain what their purpose is and how they are to be activated out-of-the-jar!

• The .jar file(s) must be delivered as an attachment(s) to a single mail sent to c02152@imm.dtu.dk.

   
  The subject line of the mail must be "Man2-NN" where NN is your two-digit group number, e.g. Man2-62

  The format of the body of the mail is free, but must comprise your student numbers and names for identification purposes.

  Furthermore, the mail body should include detailed instructions for running the various server and client programs.

  The mail must be sent before the deadline.

Help

There will be assistance for the assignment in the G-databar, building 308, rooms 15+16, as indicated on the activity plan.

Hans Henrik Løvengreen, Nov 10, 2008