How must be chat app. with protocols ?

[bahtiyor ahmedov]

I have found IBM 's whitepaper for "how must be simple client/server chat application".
Problem is: how must be architecture of more complex chat application with PROTOCOL like:
(-r <nick> <name> <pwd> // register new user)
(-s <nick> <pwd> // signin user)
(-q //quit from chat)
and others.
For example, I have code
ChatClient - start client
ClientThread - din/dout
ChatServer - start server
ServerThread - din/dout for every chat client

[Rob Spoor]

The more object oriented approach would be to define an interface or class, Command (extends / implements Serializable). These have one method for executing the command on the server. In pseudo code:

public interface Command extends Serializable
{
    public void execute(); // possibly needs parameters like ChatServer
}

You construct command objects and send these using ObjectOutputStream and receive them using ObjectInputStream. The Command class / interface could have multiple sub classes, one for each command you want to support. For instance you could have a RegisterCommand, SignInCommand, QuitCommand, MessageCommand (for regular messages). You can then use a factory method for constructing commands from Strings:

public class CommandFactory
{
    // make it a singleton; do a search in Java in General if you don't know how

    public Command createCommand(String command)
    {
        if ("-q".equals(command))
        {
            return new QuitCommand();
        }
        // etc
    }
}

The server then retrieves one command at a time, and invokes its execute method on the server. The command will then know what to do. In pseudo code:

// client, on executing command
Command command = CommandFactory.getInstance().createCommand(userInput);
sendCommandToServer(command);

// server
while (active)
{
    Command command = receiveCommandFromClient();
    command.execute();
}

As said in my first piece of code, execute probably needs a parameter of type ChatServer, as it will need to call a method on this: register(String, String, String), login(String, String), quit(), etc. An example:

public class LoginCommand implements Command
{
    private final String nick;
    private final String password;

    public LoginCommand(String nick, String password)
    {
        this.nick = nick;
        this.password = password;
    }

    // getters for nick and password

    public void execute(ChatServer server)
    {
        server.login(nick, password);
    }
}

There may be less intricate designs, but this is probably the easiest to extend with new commands. All you need to do is:
- add the necessary method to the ChatServer
- add another Command implementation that calls this method
- modify the CommandFactory to recognize this command


You can use a similar design for responses back to the client. Types of responses can be "nick already exists" (for registering), "login failed", or "succeeded". The easiest type of response is a simple enum, or even easier a String indicating only the response message.

The protocol then changes slightly. First of all, Command.execute gets a return type:

public Response execute(ChatServer server);

public class LoginCommand implements Command
{
    ...

    public Response execute(ChatServer server)
    {
        if (server.login(nick, password))
        {
            return Response.SUCCESS;
        }
        return Response.LOGIN_FAILED;
    }
}

The protocol:

// client, on executing command
Command command = CommandFactory.getInstance().createCommand(userInput);
sendCommandToServer(command);
Response response = receiveResponseFromServer();
handleResponse(response);

// server
while (active)
{
    Command command = receiveCommandFromClient();
    Response response = command.execute();
    sendResponseToClient(response);
}

This is not much more than a simple ping-pong protocol: the client sends a command (or request) to the server, and the server sends back a response, until either one quits.

[bahtiyor ahmedov]

I have a threads synchronization problem but how to solve this problem i don't know.
Concrete problem is >>> server sends response before clientthread catches readObject()
and clientthread waits this response...

Please see my code:

class ClientThread extends Thread {

    private Client client;
    private Socket socket;
    private ObjectInputStream ois;
    private boolean quit = false;
    ...
    ClientThread(Client client, Socket socket) {
        this.client = client;
        this.socket = socket;
    }

    @Override
    public void run() {
        try {
            ois = new ObjectInputStream(socket.getInputStream());
        } catch (Exception e) {
        }
        while (!quit) {
            try {
                System.out.println("CT: Reading serverThread object");
                Response response = (Response) ois.readObject();
                System.out.println("CT: response.Message--" + response.getMessage());
                System.out.println("CT: response.Code--" + response.getCode().toString());
                if (response != null) {
                    client.readResponse(response);
                } else {
                    System.out.println("Null response");
                }
            } catch (Exception e) {
                System.out.println("Error: on listening server response");
                quit = true;
                break;
            }
        }
        System.out.println("CT quit..");
    }
}

And here is my ServerThread:

class ServerThread extends Thread {

    private ObjectInputStream ois;
    private Socket socket;
    private boolean quit = false;
    private Server server;

    ServerThread(Server server, Socket socket) {
        this.server = server;
        this.socket = socket;
    }

    @Override
    public void run() {
        try {
            ois = new ObjectInputStream(socket.getInputStream());
        } catch (Exception e) {
            System.out.println("ERROR: (ST) in socket inputStream");
        }

        while (!quit) {
            try {
                Command command = (Command) ois.readObject();
                System.out.println("ST-----readobject:" + command.toString());
                Response response = command.execute(server);
                server.sendResponse(socket.getOutputStream(), response);
            } catch (Exception e) {
                System.out.println("ERROR: socket command reading");
                break;
            }            
        }
        System.out.println("ST: quit....");
    }
}

[Rob Spoor]

Your protocol is broken; the client will never send anything. Now I must admit, the requests (commands) and responses have different triggering mechanisms so it is a good thing to separate them, but the overall protocol must be as follows:
client: send request; receive response; repeat
server: receive request; send response; repeat

As your requests are sent as triggered by the GUI you cannot initiate anything without the GUI's help.

How I envision this:

Client GUI thread (Swing's Event Dispatcher Thread): gathers user input (notified by ActionListener or some other listener), sends a Command through the Socket to the client.

Client receiving thread (ClientThread): indeed wait forever until a stop response has been received. If the client is closed you can try to interrupt / terminate this thread. When a response is received notify the GUI thread (EventQueue.invokeLater).

Server thread (ServerThread): basically how you have it now; alternate in receiving, calculating the response, sending the response.


The GUI will still alternate between sending and receiving, only in two different threads. The order will be this:
1) Client GUI thread sends a command
2) Server thread receives the command
3) Server thread calculates the response
4) Server thread sends the response
5) Client thread receives the response
6) Client thread lets client GUI thread handle the response

Now the next command can be sent anywhere after step 1, but for each command sent this is the order of events, and because the server receives commands and sends responses in order of sending the client also receives responses in order, notifies the GUI thread in order and that one will handle them in order.