Homework 8 - Threads and Sockets: A chat room

Reading: Chapter 13.

Due: At 10pm, March 10, 2005. Late work will be accepted for 48 hours past the due date, with a one point penalty for each hour late.

Purpose

The purpose of this assignment is to become familiar with creating threads and using sockets. This is an example of client/server computing.

Program Description

For this assignment you will create two programs that will function like an Internet chat server and client. One program will begin listening for incoming "calls" using accept(). The other program will attempt to connect to some already started server. It is possible but not required that all of this functionality be included in a single program.

There are two parts to this program. Part 1 alone is worth a maximum of 70% for this assignment. For full credit you need to complete part 2 also. For part 1 you can create a text only version of the chat room. You are strongly encouraged to complete this part first and then modify the result to complete part 2. Part 2 is a chat room with a graphical user interface. Providing that your part 2 program is working you do NOT need to turn in a separate part 1 text only version of the program.

Part 1: A text only chat room.

Both versions of the chat server program must accept a command line argument that is the port number used for connections by clients.

Both versions of the chat client must accept a server hostname/address, a port number, and a screen name as commond line parameters.

You program must adhere to the following very simple protocol.

All communication is done using Unicode character streams (e.g. java.io.Reader and java.io.Writer).
When the client first connects, it sends "cmps109\nscreenName\n". The "\n" is a newline character, not a backslash and an n.
The cmps109 is used to let the server know that this is a proper client trying to connect. If a client does not send "cmps109" as the first line, the server should immediately terminate the connection with the client.
The screenName is the name that will be used to identify the user in the chat area.
After receiving a legitimate connection request from a cleint, the server should send a list of currently connected client names (excluding the newly connected client) to the newly connected client. This list has the following format:
```
%
name1
name2
...
%
```
If a client does not receive a properly formatted list from the server, the client should terminate the connection immediately and exit. If the list is properly formatted, the client should print:
```
This chat room is currently occupied by:
name1
name2
...
```
Next, the server sends a message "[screenName ENTERED THE ROOM]" to each currently connected client, including the newly connected client.
After that, anything sent by the client is sent back out to all currently connected clients (including the client that sent the posting). The message sent by the server to the clients should contain the screenName of the client making the posting in square brackets (e.g. [charlie]), followed immediately by the actual posting. There should be no added space between the close bracket and the message (e.g. [charlie]How are you?). Each message is terminated with a newline character.
When the server detects that a connection has been broken, it should send a message "[screenName LEFT THE ROOM]" to each currently connected client. The client should display the message to the user.
In the part 1, text only, version of the client, the client has no means of displaying the current list of room occupants to the user. That is, the client does not need to keep track of who is in the room and can safely discard the initial list of room occupants.
The clients display the messages as they are received from the server (including messages that originated at the client displaying the message), so that all clients display the messages in the same order.

For this simple version of the program it will be fine to have a message from another client (via the server) get mixed up with the message a user is typing. That is, if you are in the middle of typing a message and another person sends a message, that message will appear right in the middle of your incomplete message. On unix machines (that includes Mac OS X), the user can type control-R (that is the control key plus the R key) to have there partial message retyped without the mixed in user message. For example, in the following excerpt, user charlie is trying to type "How are you?" when user linda sends "good morning".

How are y[linda]good morning
^R
How are you?
[charlie]How are you?

User charlie type control-R and then finished the message by typing "ou?".

Part 2: A GUI for your chat room.

The graphical interface for the client must satisfy the following.

There should be one text area that displays the chat room messages received from the server.
There should another text area where the user composes messages to be sent to the chat server.
There should be a send button that sends the contents of composition text area.
In addition to sending a new message when the send button is clicked, if the user hits the enter/return key with focus in the composition text area, then the message should be sent, just as if the send button had been clicked.
The client should display the list of currently connected clients in a separate component. This can be another text area or some other component such as a javax.swing.JList. The initial list is given by the % delimited message specified above.
The list of occupants needs to be updated whenver the client receives either an "entered the room" or "left the room" message. This is in addition to displaying the enter/leave messages in the main chat room text area.

Extra Credit

For this assignment you can provide some additional features for up to 20 points of extra credit. These extra credit points can only be used to make up for deficiencies in earlier programs. In no case will anyone's total for all 5 programs exceed 100%. No bonus points will be assigned to any program that has a score below 90% without considering added features. That is, I do not want to encourage students to add features without first completing a fully functioning and stylistically correct basic version.

(5 points) Allow the user of the gui client to disconnect and then reconnect to the same or a different server without exiting the program. How you obtain the new port number and hostname is up to you (e.g. menu, popup, separate component).
(5 points) Use different colored text for each user to help with reading the content of the main chat room.
(5 points) Your cool ideas here.

How to proceed

You can start with MiniServer and MiniClient. The biggest difference between these programs and your program is that they contain only one thread each. Each thread is either listening to the local console (Console.in.readLine()) or listening to the network (input.readLine()). For this assignment you will need more than one thread in both the server and the client.

In the client you will need

one thread that responds to user actions (e.g. typing in message in the part 1 version or clicking the send button in the part 2 version), and sends messages to the server. For the part 2 version you can just use the AWT event thread for this. In the text version you will need to create a separate thread.
The client will also need a thread that listens to the socket and displays those messages to the user. You can use the main thread for this.

In the server you will need

one thread for each connected client. These threads listen for incoming messages from the associated client, and then send these messages to some object on the server that is responsible for sending the newly received message out to each of the clients. You may also decide to have a separate thread that is doing the actual sending of messages to the clients. Think producer/consumer with a buffer. The servers threads associated with each connected client are "producing" messages for transmission to the other clients. The server might then have a "consumer"thread (just one) that consumes these buffered messages by sending them out to all currently connected clients. You probably do not want one "consumer" thread for each connected client. That would unnecessarily complicate the design.
The server also needs a thread to listen for new client connections.

You will need to follow every write to the output stream of a socket with a call to flush() to force the output stream to actually send your message over the socket. Without the flush() the output stream may try to buffer up several messages before sending it out over the socket.

Sample Solution

I also have a sample solution (not heavily tested) available. There are two jar files, chatServer.jar and chatClient.jar in /afs/cats/courses/cmps109-cm/hw5. To run the server type:

         java -jar chatServer.jar portnum

To run the client type:

         java -jar chatClient.jar hostname portnum screenName

You can start several command windows and use "localhost" as the host name.

There is also a text only client. To run it you will need to extract the class files from either of the jar files (they actually contain the same class files, just a differrent Manifest saying which file is main). To run the text only client type:

jar xf chatClient.jar
cd hw5
java TextClient hostname portnumber screenName

Doing your own work

As a final reminder. The program you submit must be your own original work. If you use code snippets from other example programs you find in text books etc. you MUST give them credit by clearlly indicating in your comments where the code came from. I'm sure there are complete Java chat programs out there in the Internet somewhere. You should not use significant portions of other existing programs (beyond MiniClient and MiniServer). If you find a code snippet you would like to use and you have any questions about whether it is appopriate, don't hesitate to ask me (Charlie McDowell).