CS 5523 Operating Systems
Laboratory 1 Post Mortem
Proxy Monitor

Threading and timing errors:
- Assumed that client sends the request and then server responds. (This is not the specification. You must have two threads capable of simultaneously transferring information.)
- Assumed that the entire request could be read in a single read, provided the buffer was big enough. (This only works on a fast local network. TCP provides an abstraction of a stream of bytes without packet or message boundaries. You have no control over how much will be delivered in a single read.)
- Did not measure the time to process the client requests in the tunnel program. (The specification for the tunnel asked you to measure the time of the client communication.)
- Incorrectly measured the time to process the client requests. (Some people measured the start time after the accept and the end time after the thread creation. This placement measures thread creation time, and indicates to me that you do not understand thread flow of control. The end time should be measured after the join.)
- Measured time values that were completely unreasonable. (One person had times in milliseconds that were equivalent to several years. Look at the output to see if it is reasonable.)
- Used sleep in the threads to inappropriately force synchronization. (When I see sleep(1000) in random places in a program, I know it doesn't work right.)
- Logging one line at a time to the log file. (The log file is a shared resource. To really do this right, you should accumulate the header in a StringBuffer. When the header is complete, the thread should write to the log file. Actually a good approach is to have a separate LogFile class and make its write method synchronized.)
- Connected to the destination web server from the tunnel before accepting a client connection. (If you type fast, you might not notice a problem. In a real implementation, the destination web server will disconnect after a fairly short time period when no incoming request appears.)
Bad parsing and logging strategies:
- Used indexOf("\n\r") to parse the header from the resource. (In most cases, this approach resulted in taking the first line of the response instead of the entire header.)
- Parsing inline in the main loop. (When I see this, I know that you didn't test your parsing method very well--- how could you? You should remove your parsing code from the main loop, put it in a method, or better a class and test it separately.)
- Treated the resource as a String. (Several people were confused by the parsing and the difference between a byte and a character in Java.
Uncaught exceptions, badly caught exceptions, and bad exits:

Did not seriously or correctly address the problem of when the servers should exit. (In general a client should NOT be able to cause a server to exit. The server should only exit if there is an irrecoverable error due to resources (memory, descriptors, etc) that would jeopardize future correct execution. Remember the Mars Pathfinder! For this program, the only place the server should exit is when it fails to create a ServerSocket.)
Exited on a bad accept or in random methods throughout the program.
Exited if the proxy fails to connect with the destination web server.
Allowed exceptions to go uncaught. (An uncaught exception anywhere causes the program to exit. This means that each close must be in a try-catch.
Put multiple close calls in the same try-catch. ( Method calls that release system resources (e.g., close) and might throw exceptions MUST be in their own try-catch block. For example:
```
   try {
      x.close();
      y.close();
   } catch ....
```
If x.close throws an exception, the socket resources for y will not be released. Similar problems occur when you put the close in the try-catch in which you do I/O. In both cases, a long-running server will soon exceed its resources.
When a communication thread gets an I/O exception, it should close both sockets. Some people only closed one, resulting in the program hanging.
Improper messaging when an exception occurs. (You need to think about when you want to print a message in response to an exception and when you don't. Most exception messages should go to System.err not to System.out.)
Improper order in catching exceptions. (You want to catch most specific exceptions first...at most one will be caught.)
Failed to close both sockets in a thread. (If your program behaved correctly, you got lucky.)

Writing style and presentation:
- Spelling and grammar. (Yikkes! Use a grammar checker and pay attention to those green underlines, please!)
- Including completely irrelevant information in the introduction (to make the report look longer?)
- Changing style, typeface, number scheme or bullet style in the middle of the report. (Use Times-Roman 12-pt type so I don't go blind. )
- Poor layout and organization. (Please follow the guidelines for the reports.)
- Presented the entire report in a single paragraph or in very long paragraphs. (Use paragraphs. If you have a single-spaced paragraph that is a third of a page or more, you probably need more paragraphs or to be more concise.)
- Inappropriate or lack of section titles. (Bold face the section titles and make the section titles correspond to what the section is about. Your goal is to convey information, not to challenge the reader's logic skills.)
- Excessive use of code in the report. (Some people pasted parts of their programs into the report. Use outlines, pseudocode or block diagrams to convey implementation details.)
- Excessive use of "it". (After 20 sentences that start with "it" on the same page, the reader won't know what it you mean. My personal style problem is starting too many sentences with "This is". Some of you also have this problem.)
- Gave separate architectural diagrams for the tunnel and proxy, but the diagrams were identical. (If the diagrams are going to be the same, you should give one diagram and refer to it when discussing both items.)
- Gave a confusing diagram. (Diagrams are very useful and can greatly improve the clarity of the presentation, but a diagram that conveys the wrong idea is worse than no diagram. Ask yourself, what information you are trying to convey by the diagram. For example don't use the same style box to represent both a process and a port number, or the same type of arrow to represent a connection request and a thread.)
- Didn't answer the questions. (The specification asked several questions that you were supposed to answer.)
Poor testing and presentation of results:
- Did not prove that the program correctly transmitted the files. (Although it might appear that your program is working because the browser displays a page, you must test that the program correctly transmitted the data. For the tunnel, you should have first tested between a modified TCPClient and TCPServer to make sure that the tunnel correctly transferred random files in both directions --- including binary files. I could tell from reading code that contained BufferedReader or readUTF or used String for the files, that this was not done and that the test cases had been carefully selected.)
- Did not adequately explain the tests. The typical approach was a short paragraph saying the program worked. A large log file was then included. (A good approach might be to organize your test results into a table with an annotation of what that test result was supposed to show and a column with page numbers of the output so that the reader can actually see the tests.)
- Random tests. (You should think about what you are trying to test for --- different types of web pages, different types of servers, different network connections, different times of day, etc. and clearly organize your tests.)
- Did not state conditions under which experiment was run (machines, times of day, etc.)
- Did not give an analysis of what happened, what you expected to happen and what actually did happen.
- Assumed everything was a String. (Clearly you didn't run tests with binary objects---or at least didn't mention it.)
Programming errors and bad style:
- Big or inconsistent indentation.
- Big loops - use helpers to remove complexity. For example, parsing the GET line should be done in a helper.
- Don't reinvent the wheel. (For example the URL class has everything you need to parse a URL.)
- Used String to concatenate characters in a loop --- which results in copying to a completely new String on each concatenation. (Use StringBuffer which is like String, but supports mutable strings.)
- Wrote completely different programs for the two directions on the proxy, when most of the code is the same. (A second constructor where you pass the parsed GET would be good here.)
- Assumed that what was read would not exceed some arbitrary, predetermined size. For example, some people assumed that the entire header would fit in a specified number of bytes or was less than a specified number of lines, say 50. (When I see a buffer of 400000 bytes stuck in the code, I immediately suspect that code isn't working right.)
- Not creating new classes to encapsulate complex operations, say logging or parsing. (As you become more experienced with OO programming, you will start to think in these terms, and your programs will greatly improve.)
- Wrote error messages to System.out instead of to System.err.
- Proposed a naming convention for the resource files in the report and then didn't follow it in the program.
- Hard-coded buffer sizes into the program. (Use predefined constants with static final for buffer sizes if they have to be fixed size. Then you only have to change the values in one place and you know what the values represent.)
- Used port 80 all of the time for the proxy. (Port 80 should only be used as the default, if the URL does not include a port number.)
- The command line arguments were not used or were used incorrectly.

Last revision: April 6, 2002 at 1:10 pm by Kay A. Robbins

CS 5523 Operating Systems Laboratory 1 Post Mortem Proxy Monitor

CS 5523 Operating Systems
Laboratory 1 Post Mortem
Proxy Monitor