INFO I211 Lab 7
Palindrome Client/Server and Unix Utilities

Due date: extended to April 16, 2012; last chance April 23, 2012, 11:59 p.m. EDT
60 points

Warning

Instructions for this lab are likely to change.

Teamwork

Two students may work as a team on this project. Working together is recommended for this project. Student teams will turn in one copy of their solution and will receive equal credit for their work.

Learning Objectives

  1. Learn about a few useful Unix/Linux programs for finding files, compression/decompression, identifying file types, and determining the differences between files.
  2. Learn about the sockets API for distributed (networked) programs.

Part A: Other Useful UNIX Commands

  1. Read the UNIX/Linux Tutorial for Beginners, Part Six.
  2. We do not have quotas on merlin, so the `quota` command will show no output.
  3. Practice the commands, including `df`, `du`, `gzip`, `gunzip`, `zcat`, `file`, `diff`, `find`, `history`, `!!`, and `!`. Save evidence of your practice — this can be one or more screenshots, or copy from the terminal and paste into a plain text file.

Part B: Palindrome Testing: Client and Server

Overview

Develop the palindrome checker of Lab 4 into a client-server application.

Learning objective: ability to develop a program with network communication using sockets.

Prerequisites: Chapters 1–6 and 11; lecture notes on network I/O.

Requirements

  1. The client provides a graphical user interface, as in Lab 4.
  2. The client connects to a server and sends as many "potential palindrome" strings to the server as the user requests.
  3. When the user gives the quit command, the client disconnects from the server and then halts.
  4. The server accepts connections from clients. It can serve multiple clients, one after another. It is not necessary to serve multiple clients simultaneously.
  5. When a client connects, the server receives queries from the client about a string t — is it a palindrome? The server determines whether it is a palindrome and sends the decision to the client.
  6. When the client receives the decision from the server, it displays the result to the user as in Lab 4.
  7. The server does not have to have a graphical, or even a friendly, user interface. It is sufficient to start the server with a command such as java MyServer 8123, where 8123 is the port on which the server will listen for connections; and terminate it with control-C.

Hints

Design Hints

  1. There should be at least three classes: a client class providing the GUI, a server class handling communication with the client, and a palindrome tester class which handles the application logic. This separation of application logic from interface will make your work easier.
  2. Keep the protocol simple—the rules for communication between client and server. Here is a suggested protocol. Each message should be a line: that is, end it with "\n\r" or just use the println method to send it and the Scanner.nextLine method to receive it. The client just sends the string to be tested, the server send a response of "yes" or "no", and the client can just disconnect when finished, like this:

    CLIENT: lol

    SERVER: yes

    CLIENT: lack

    SERVER: no

    (CLIENT disconnects)

  3. Team developers should agree on the protocol first. Then one person can work on the client while the other works on the server.

Development Hints

  1. Develop client and server separately. Test each one using nc before putting them together. Don't expect them to work together unless each one works separately.
  2. Run the server on merlin.iue.edu using a port in the range of 8000–8999. merlin will accept incoming connections on these ports, but only from the Linux lab or from merlin itself.

Remarks

It is a good idea to separate the user interface of a program from its application logic. The user interface has to do with how it interacts with the computer user, getting inputs and delivering outputs; the application logic has to do with how it processes the data. Most of you did not separate these two concerns in Lab 4. If you had separated them, you would find this new lab a bit easier.

So, why didn't I tell you that back in Lab 4? Well, if I had, would you really learn the lesson? Or do you need to experience the consequences of bad program design, in order for the virtue of good design principles to sink in?

What to Turn in

Pairs of students who work together: Make sure that both of your names appear on all submitted source files, in the header comments. Either student may submit the work in Oncourse Assignments 2, but must credit the other student as a partner in the "Submitted text" for the assignment.

Grading Criteria

TOTAL: 60 points