A thread-safe FIFO queue. You implemented this as part of Workbook 3. Copy your implementation into the package uk.ac.cam.crsid.fjava.tick4.

public class MultiQueue<T> {
 private Set<MessageQueue<T>> outputs = //TODO
 public void register(MessageQueue<T> q) {
  //TODO: add "q" to "outputs";
 }
 public void deregister(MessageQueue<T> q) {
  //TODO: remove "q" from "outputs"
 }
 public void put(T message) {
  //TODO: copy "message" to all elements in "outputs"
 }
}

The server should contain a single instance of a MultiQueue object, regardless of the number of clients connected to the server. The instance should be specialised to process objects of type Message, although in practise there should only ever be RelayMessage or StatusMessage objects (i.e. server to client messages) and never any ChatMessage or ChangeNickMessage objects stored in the MultiQueue object. Internally, the MultiQueue object should store a list of active SafeMessageQueue objects associated with clients, and whenever a new message is added to the MultiQueue object through the put method, your implementation should copy the message to every registered SafeMessageQueue object.

To maintain a current list of active clients, the MultiQueue object must support register and deregister methods. All three methods (put, register and deregister) are, in general, invoked by multiple instances of ClientHandler, and as such you must ensure that MultiQueue is thread safe! You can do so by making appropriate use of the Java synchronized statement to prevent concurrent access to outputs by taking out a lock on this whenever the body of any method is invoked.

public class ChatServer {
 public static void main(String args[]) {
  //TODO
 }
}

This class should contain the special main method which is executed when the Java chat server is first started. Your implementation of the main method should expect an integer value representing the port number the server should start on as a single argument on the command line. If there are no arguments (or a malformatted argument) is found, your implementation should print out

Usage: java ChatServer <port>

and your implementation should then terminate.

If a port number was correctly provided by the user then the main method should create a single instance of java.net.ServerSocket by providing the port number entered by the user to the constructor of this class. If, for some reason, the Java chat server cannot use the provided port number (e.g. the port is already occupied by another server) your implementation should print out

Cannot use port number <port>

where <port> is the port number entered by the user and then terminate.

In addition to creating an instance of ServerSocket, your implementation of the main method should also create a single instance of the MultiQueue class. After the initialisation of an instance of ServerSocket and MultiQueue your implemention should sit in a loop forever doing the following things:

public class ClientHandler {
 private Socket socket;
 private MultiQueue<Message> multiQueue;
 private String nickname;
 private MessageQueue<Message> clientMessages;
 //TODO: possibly other fields here
 public ClientHandler(Socket s, MultiQueue<Message> q) {
  //TODO
 }
 //TODO: Other code here as necessary
}

This class handles the interaction between the Java chat client and the MultiQueue object. This class should provide a single constructor which takes two arguments: a reference to the Socket object associated with the Java chat client and a reference to a MultiQueue object. The constructor should do the following:

When the Java chat client disconnects, the Java chat server will receive an IOException. Handle this exception in the ClientHandler by calling the deregister method on multiQueue appropriately and create and send a StatusMessage object to all the remaining clients. When the Java chat client disconnects, you must ensure that both the threads used to handle incoming and outgoing threads terminate. (If you don't, your Java chat server will eventually fail, since every new Java chat client which connects creates a new instance of ClientHandler, and when they disconnect the incoming and outgoing threads don't finish and so continue to consume memory on the server.)

You have now completed all the necessary code to gain the fourth ticklet. Your repository should contain and make use of the following source files:

src/uk/ac/cam/crsid/fjava/tick4/ChatServer.java
src/uk/ac/cam/crsid/fjava/tick4/MessageQueue.java
src/uk/ac/cam/crsid/fjava/tick4/SafeMessageQueue.java
src/uk/ac/cam/crsid/fjava/tick4/MultiQueue.java
src/uk/ac/cam/crsid/fjava/tick4/ClientHandler.java
src/uk/ac/cam/cl/fjava/messages/ChangeNickMessage.java
src/uk/ac/cam/cl/fjava/messages/NewMessageType.java
src/uk/ac/cam/cl/fjava/messages/RelayMessage.java
src/uk/ac/cam/cl/fjava/messages/StatusMessage.java
src/uk/ac/cam/cl/fjava/messages/ChatMessage.java
src/uk/ac/cam/cl/fjava/messages/Message.java

When you are satisfied you have completed everything, you should commit all outstanding changes and push these to the Chime server. On the Chime server, check that the latest version of your files are in the repository, and once you are happy schedule your code for testing. You can resubmit as many times as you like and there is no penalty for re-submission. If, after waiting one hour, you have not received a final response you should notify ticks1b-admin@cl.cam.ac.uk of the problem. You should submit a version of your code which successfully passes the automated checks by the deadline, so don't leave it to the last minute!