Chapter 3: A Larger Example: SocketChat

Size: px

Start display at page:

Download "Chapter 3: A Larger Example: SocketChat"

Geoffrey Taylor
6 years ago
Views:

1 page 1 Chapter 3: A Larger Example: SocketChat In this chapter we are going to look at three versions of a larger socket-based example: a simple `chat' application. The application does not have many capabilities, and the implementation would not scale up very well to large numbers of clients. But it does illustrate a number of issues. You can download the code: The The Client source. The The Server source. The The Message object class. We are going to consider three versions of this application, all of which differ only in how the server is implemented. The first version is wrong, and illustates a common error. The second corrects it and works correctly; the third gets rid of an obvious inefficiency Client The client consists only of two scrollable text panes: one containing text you type, the other text typed by others. The first line of text you type is your name - you can't change it afterwards and it doesn't have to be unique (I said it was basic). The user interface is based on the Swing API. To send a message, just type text (making sure the input textarea has focus - we could fix that programatically) and hit return. Note that strictly we're breaking some rules here since we're using multiple threads with a Swing interface. Swing is not inherently thread safe, and you're supposed to use special techniques to build threaded Swing applications. However, since our second thread is exclusively in control of one GUI component, we're very unlikely to have trouble (that's my excuse anyway). Here's the first chunk of code, leaving out the import statements (check the actual source file): import java.io.*; import java.net.*; import javax.swing.*; public class AppChatClient { private void initcomponents(string host) { mytext.addkeylistener(new java.awt.event.keyadapter() { public void keytyped(java.awt.event.keyevent evt) { texttyped(evt); ); Socket mysocket = new Socket(host, Message.getSocketNumber()); othertextthread = new TextThread(otherText, mysocket); OutputStream temp = mysocket.getoutputstream(); out = new ObjectOutputStream(temp); othertextthread.start(); frame.addwindowlistener(new WindowAdapter() { );

2 page 2 catch (Exception ex) { othertext.append("failed to connect to server."); private void texttyped(java.awt.event.keyevent evt) { public static void main(string[] args) { if (args.length < 1) { System.out.println("Usage: AppChatClient host"); return; final String host = args[0]; javax.swing.swingutilities.invokelater(new Runnable() { AppChatClient client = new AppChatClient(); public void run() { client.initcomponents(host); ); The main method creates all the user-interface components by calling initcomponents() (the javax.swing.swingutilities.invokelater stuff just makes sure the GUI gets started in the event handling thread, it's not important here; and the frame.addwindowlistener stuff just makes sure that an exit message is sent to the server when the client closes). initcomponents also sets up the socket. Rather than hard-code the socket hostname/ip address in the source, it's passed in as a command-line parameter. Similarly, the socket number is not hard-coded in the client, but is in the Message class, used to pass messages between client and server (and which is therefore available to both). Next an object output stream is attached to the socket. This will allow us to send complete Java objects between the server and client. This is a somewhat more sophisticated solution than just sending strings, but does mean that it is more difficult for us to make the server and client language independent. A more flexible alternative would be to use XML - which is one of the ideas behind XML Web Services. More on them later in the module. Next, it creates and starts a thread of the class TextThread. We will look at this later in the chapter, but briefly we need it because messages from other clients may arrive (via the server) at any time, and we need a separate thread to read and display them. Strictly, because the GUI is already in another thread, we could get away without doing this - but doing so makes it explicit, and clearer (to me, anyway). The rest of the client is made up of three methods. The first, initcomponents() is mainly concerned with setting up the GUI, and we will not show all of it. The only interesting bit is: mytext.addkeylistener(new java.awt.event.keyadapter() { public void keytyped(java.awt.event.keyevent evt) { texttyped(evt); ); which adds a key listener, directing keyboard events to the method texttyped. texttyped is the next method: private void texttyped(java.awt.event.keyevent evt) { char c = evt.getkeychar(); if (c == '\n'){ Message m; if (firstmessage) {

3 page 3 m = new Message(Message.NAME_MESSAGE,textString); firstmessage = false; name = textstring; else { m = new Message(Message.NORMAL_MESSAGE,textString); out.writeobject(m); catch (IOException ie) { othertext.append("failed to send message."); textstring = ""; else { // In general, this is not efficient - // StringBuffer is better // but efficiency is not really an issue here. textstring = textstring + c; Everytime a key is pressed, this is called. If the key is not a carriage return, then we simply append the character to textstring. Otherwise, we create a Message object, including the text string, and send it to the server using the ObjectOutputStream class' method writeobject. If this is the first message from this client, then the message type is NAME_MESSAGE; otherwise it's NORMAL_MESSAGE. The remaining class in the client is the very simple TextThread: class TextThread extends Thread { ObjectInputStream in; JTextArea othertext; Socket socket; TextThread(JTextArea other, Socket mysocket) throws IOException { othertext = other; socket = mysocket; public void run() { in = new ObjectInputStream(socket.getInputStream()); while (true) { Object message = in.readobject(); if ((message == null) (!(message instanceof Message))){ othertext.append("error reading from server."); return; Message m = (Message)message; switch (m.gettype()) { case Message.NORMAL_MESSAGE: othertext.append(m.getmessage()); case Message.NAME_MESSAGE: othertext.append(m.getmessage() + " has joined."); case Message.EXIT_MESSAGE: othertext.append(m.getmessage() + " has left the building."); default: othertext.append("error reading from server."); othertext.append("\n");

4 page 4 catch (Exception e) { othertext.append("error reading from server."); return; The constructor attaches an ObjectReader to the socket, and then continually reads objects sent by the server, extracting and displaying the actual message (details depending on the message type) Communicating: Messages The clients and server communicate by sending Message objects to each other. This is arguably a bit inefficient, and a simple string would be enough (when I used to set this as coursework, nearly everyone sent strings). Using objects does make it easier to send other information (we send a message type integer), and also makes it easier to make changes (strictly, if you are careful with the code, this can be true of just sending strings). public class Message implements Serializable { private static final long serialversionuid = 42L; private static final int SOCKET_NUMBER = 1664; public static final int EXIT_MESSAGE = 0; public static final int NAME_MESSAGE = 1; public static final int NORMAL_MESSAGE = 2; public static final int INVALID_MESSAGE = -1; private final String message; private final int type; public Message(int t, String m) { message = m; type = t; public static int getsocketnumber() { return SOCKET_NUMBER; public String getmessage() { return message; public int gettype() { return type; This should be pretty straightforward - there's a constructor and accessor methods for the two private fields, as well as constants for the message types identified so far. Slightly controversial is the inclusion of SOCKET_NUMBER (and it's accessor) here. Normally, I put all global(ish) constants in a separate class, with an accessor (having an accessor makes it easier to change them later from simple constants - to, say, database entries). However in this case there is only one such constant and it seems a bit excessive to have a class for it Servers: Common Code Server versions 1 and two differ only in one method, and version 3 only by one method and a class, so we can save ourselves a lot of code by using an abstract class and interfaces. It's debatable if this actually makes it easier to read or not (and I'm not going to do it in the RMI Version. But I think sometimes that not everyone is convinced of the usefulness of concepts like abstract classes and interfaces, and an illustrative example is quite useful. interface IsServerThread extends Runnable {

5 page 5 public void writemessage(message message); We will inplement this interface with an abstract class ServerThread, and then subclass this with ServerThread1, ServerThread2 and ServerThread3, which provide different implementations of the one abstract method propagate (not the one in the interface, notice). Strictly, the interface is not necessary but in general it is good practice. The interface extends runnable interface, so any implementation of IsServerThread can run as a thread. The following interface and class are only needed to incorporate version 3 along with 1 and 2 - for 1 and 2 we could just get away with any Collection object. interface IsServerList { public void add(isserverthread item); public void remove(isserverthread item); public void inccounter(); public void deccounter(); public Collection getcollection(); All versions will store client threads in objects that implement the IsServerList interface. The first two versions don't need the counter methods, so BasicServerList below just encapsulates an ArrayList (though note we can replace it with any Collection object. The getcollection method extracts the encapsulated Collection object - easier than implementing Collection, returning it's own iterator etc., etc. class BasicServerList implements IsServerList { private Collection<IsServerThread> threadlist = new ArrayList<IsServerThread>(); public void add(isserverthread item) { threadlist.add(item); public void remove(isserverthread item) { threadlist.remove(item); public void inccounter() { public void deccounter() { //Note it is *not* a bug that it isn't synchronized public Collection getcollection() { return threadlist; Here is the important part of the main method: ServerSocket ssoc = null; ssoc = new ServerSocket(Message.getSocketNumber()); catch (IOException e) {

6 page 6 //Use BasicServerList for versions 1 and 2, ServerList for 3 //IsServerList serverlist = new BasicServerList(); IsServerList serverlist = new ServerList(); while(true) { Socket insoc = ssoc.accept(); //Uncomment the appropriate lines to switch implementations /*IsServerThread newserverthread = new ServerThread1(inSoc, serverlist);*/ /*IsServerThread newserverthread = new ServerThread2(inSoc, serverlist);*/ IsServerThread newserverthread = new ServerThread3(inSoc, serverlist); new Thread(newServerThread).start(); catch (IOException e) { We create a ServerSocket, then wait for connections. Each connection results in a new thread being started. The only interesting lines are IsServerThread newserverthread = new ServerThread?(inSoc); and IsServerList serverlist = new [Basic]ServerList(); where we use the interfaces The Abstract Class Here is the abstract class: abstract class ServerThread implements IsServerThread { protected static IsServerList threadlist; private ObjectInputStream in; private ObjectOutputStream out; private String name; { public ServerThread(Socket insoc, IsServerList list) throws IOException threadlist = list; in = new ObjectInputStream(inSoc.getInputStream()); out = new ObjectOutputStream(inSoc.getOutputStream()); synchronized (threadlist) { threadlist.add(this); public void run(){ boolean notfinished = true; while (notfinished) { Object rawmessage = in.readobject(); if (!(rawmessage instanceof Message)) {

7 page 7 Message message = (Message)rawMessage; //This could represent a client that has //exited if (message == null) { notfinished = false; switch (message.gettype()){ case Message.NORMAL_MESSAGE: case Message.NAME_MESSAGE: propagate(message); case Message.EXIT_MESSAGE: propagate(message); notfinished = false; default: //Ignore any other values - they are errors. Thread.yield(); //In case we don't have native threads catch (IOException ie) { System.out.println("IO Exception"); ie.printstacktrace(); catch (ClassNotFoundException cnfe) { //Clean up finally { synchronized (threadlist) { threadlist.remove(this); //Write out to this thread's client public void writemessage(message message) { if (message == null) { System.out.println("Null message"); else { out.writeobject(message); catch (Exception e) { abstract protected void propagate(message message); There are three methods and a constructor. Constructor. The constructor attaches input and output object streams to the socket connected to the client, and adds an instance of itself to a Collection object. This final action is synchronized - we need to protect access to the Collection thread list. We could have used the already-synchronized Vector, instead of ArrayList. However, this would have constrained our options later on. run.the run method is required, since ServerThread implements Runnable. This method does most of the work: reading objects, making sure they are Message objects, and then deciding what to do with them. The finally clause is executed as the method exits, and it removes itself from the thread list (also synchronized).

8 page 8 writemessage. This handles the low level details of actually sending an object to an individual client. propagate. This is the abstract method. It will be responsible for distributing a message to all active clients (by calling writemessage). This contains multiple instances of the use of interfaces. We are using the interface IsServerThread to determine what can be stored in the ArrayList. We also use Collection so we can trivially replace ArrayList with some other implemenation of Collection. Both of these steps make later code changes easier The First Wrong Server Version Our first implementation has a subtle error. It contains the same error that occurs if you simply use Vector instead of ArrayList and think that because Vector's synchronized, all your problems are over. However, synchronization issues are usually more complex than that. class ServerThread2 extends ServerThread { public ServerThread2(Socket insoc) throws IOException { super(insoc); protected void propagate(message message) { for (Iterator i = threadlist.iterator(); i.hasnext();) { synchronized (threadlist) { IsServerThread thread = (IsServerThread)i.next(); thread.writemessage(message); This version synchronizes each individual (more or less) access to the thread list. The problem with this is that although access to the thread list is protected, there may be other threads being created/destroyed while the for loop is running. So the thread list may change during the loop. This is not guaranteed to work, or even not lead to serious failure. (In general, this is true for most for loops - they generally compute the loop bounds before they start, and then changing them during the loop is not a good idea. Are you likely to see this? This is a toy example, and with only a small number of clients then no, it's not likely. But in a real application with many clients, this problem will inevitably occur The Second Correct Server Version The solution is simple - just synchronize the whole loop: class ServerThread1 extends ServerThread { // Constructor as before protected void propagate(message message) { synchronized (threadlist) { for (Iterator i = threadlist.iterator(); i.hasnext();) { IsServerThread thread = (IsServerThread)i.next(); thread.writemessage(message); Although the server will now work properly, it does look a little inefficient (though working and inefficient is always better than not working). We only really want to synchronize access to the thread list on write operations, and prevent write operations when read operations are in progress. Multiple simultaneous reads are OK. Our current implementation however only allows a single operation (read or write) to occur simultaneously. The next version addresses this.

9 page Third (Possible) Version - Cloning A possible third approach, which we won't code, and which may be more efficient, is to clone the thread list before we send messages out to clients. This isn't as inefficient as it seems, because the copy is shallow - that is, it only copies the references to the threads, not the thread objects themselves. We don't include the code for this because we cannot use our existing abstract class - it only requires that the structure used to store the thread list implements Collection, and the clone() method is in Cloneable (ArrayList implements both). The required changes are small though, so feel free to have a go yourself Third (Actual) Version - Partial Synchronization In this version, we will develop a version that synchronizes access to the thread list only on write operations (adding, deleting threads). All read operations can proceed unsynchronized - though we also make sure that no writes can occur when reads are in progress. To start with, we need a new thread storage class. class ServerList implements IsServerList { private Collection<IsServerThread> threadlist = new ArrayList<IsServerThread>(); private int counter = 0; public synchronized void add(isserverthread item) { while (counter > 0) { wait(); threadlist.add(item); catch (InterruptedException e) { System.out.println("Addition interrupted."); finally{ notifyall(); public synchronized void remove(isserverthread item) { while (counter > 0) { wait(); threadlist.remove(item); catch (InterruptedException e) { System.out.println("Removal interrupted."); finally { notifyall(); // Similarly for changing counter public synchronized void inccounter() { counter++; notifyall(); public synchronized void deccounter() { counter--; notifyall(); public Collection getcollection() { return threadlist;

10 page 10 The add and remove methods are synchronized so only one can proceed at a time - but that in itself is not sufficient. So we also add a counter, to keep track of the number of ongoing read operations. Before starting a read operation (that is, we propagate a message to clients) we increment the counter, and when finished we decrement it - and notice that the act of incrementing/decrementing the counter is also synchronized. We can only add/remove clients when the counter is zero. Let's look at the code of one method (the other is similar: while (counter > 0) { wait(); threadlist.remove(item); catch (InterruptedException e) { finally { notifyall(); If the counter is non-zero, the method waits - i.e. sleeps, giving up the synchronization lock. It will only be woken when one of the other methods calls notifyall(), when it will check the counter again. Eventually, the counter will be zero and the method will proceed. The call to notifayall() will wake all other sleeping threads, which can then check to see if they can proceed. Here's the code for propagate: class ServerThread3 extends ServerThread { public ServerThread3(Socket insoc, IsServerList list) throws IOException { super(insoc, list); protected void propagate(message message) { threadlist.inccounter(); for (Iterator i = threadlist.getcollection().iterator(); i.hasnext();) { IsServerThread thread = (IsServerThread)i.next(); thread.writemessage(message); threadlist.deccounter();

Reading from URL. Intent - open URL get an input stream on the connection, and read from the input stream.

Reading from URL. Intent - open URL get an input stream on the connection, and read from the input stream. Simple Networking Loading applets from the network. Applets are referenced in a HTML file. Java programs can use URLs to connect to and retrieve information over the network. Uniform Resource Locator (URL)