Managing threads in Java with a good pattern

Question

This morning I began writing a minimal chat using Java socket and threads but it took some minutes for me to experience a lot of problems in the MVC management.

Currently I have 3 classes:

• Main, this is just the main class used for starting the Control.
• ChatController, I use this for managing Model and View classes (this is a Controller class).
• Host, a class containing a Socket attribute and two Scanner and PrintStream attributes for reading and writing to and from the socket.

The problem here is which class extending from Thread to let the program both read and write features concurrently. My professor told me to extend the ChatControl (hence, the Controller) class, but I think it is too much hard-coding (and also, I don't like the method/attributes inherited from Thread to be visible from the ChatController class).

So, is it correct extending the Control class from Thread for managing the thread or should I consider to implement another class for tasking this problem (or even trying some other patterns)?

If you need some source, find it on pastebin.

Answer 1

Since it seems you are limited to MVC (re: comment from professor), you may want to look at this from a slightly different direction. Consider a chat received and chat to be sent as "events" that the controller must process and dispatch. The controller can have two queues. One for processing received chats and one for sending them. The network code feeds into and out of these queues. That's at least how I would look at it because it makes the threading a little simpler to handle.

Answer 2

A Similar Exercise

What I did for an exercise using MVC, Sockets, and multiple threads was to first develop what I called the "models". This exercise was called Echo Client/Server because all that the server did was echo what each client sent to the server, back to the client that sent up the message.

My exercise was a little simpler than a chat exercise, but the two exercises are very similar in nature.

My classes:

1. The EchoServer class, the model for the server side with absolutely no user interface.
2. The EchoServerDaemon class, just a class with a main() method to create an EchoServer object and start a thread for it, one view
3. The EchoClient class, the model for the client side with absolutely not user interface
4. The EchoClientConsole, a console view of the client's input/output
5. The EchoUtils class which contains anything that the EchoServer model and the EchoClient model need, such as the default port number.

I could have added classes such as the following classes without much work because the model classes EchoServer and EchoClient were independent of their user-interfaces:

EchoServerConsole, a server with a console view EchoServerGUI, a server with a GUI view or EchoClientGUI, a client with a GUI view

1. I got the model done first.
2. Then, I got the views specified.
3. I did the controllers last, connecting the model and the view.

I believe that having multiple threads for a server is pretty much mandantory.

On the server, I had a class with one thread which I called the ConnectionListener which is an inner class of EchoServer. The ConnectionListener mainly calls serverSocket.accept() and creates connections.

I also had a thread for each connection called ConnectionServicer. Each client connection was serviced by a separate ConnectionServicer thread so that the server as a whole could call read() and write() and if the thread blocked, nothing else would freeze.

I don't think that the client needs a separate thread unless you're doing something time-consuming such as downloading a large file.

If you want me to make my source-code available, let me know.