2.1 Aims & Objectives

To enable the student to produce a Distributed Computer application, using the Java programming language utilising the TCP/IP protocol.

 

2.2 Brief

Design, implement and test a chat program using the Java programming language. The implementation may use a peer-to-peer model or a client-server model and my use connection or connectionless networking programming or a mixture of both. The minimum acceptable implementation is two Java applications which can send and receive lines of text across a network connection as well as the deliverables details below.

Extra marks will be given for additional features and functionality which enhances the user experience such as

- a graphical user interface

- logging of connections

- logging of messages sent and received

- a server based chat program which relays messages between clients

 

These extra features are only suggestions and are not exhaustive. Evidence of cross platform testing will also merit extra marks.

3.0 Design

3.1 Client Application Overview

 The application will consist of two programs. The first program will be the server that will administer all connected users, log activity and relay messages to the clients. The send application will be the client messenger application that will connect to the remote server.

When a user loads the client application, they will be required to log into the remote server. Figure 1.1 demonstrates the appearance of the login window. This will involve assigning a desired username to the session. This username will be used by the server to distinguish between different connections and therefore is important they remain unique. For example, two users cannot have the same username.

Additional the username field, the user can also specify the remote server host name or IP address and the port that the server is listening on. By default, this value will be 127.0.0.1 and port 1000. Should the application go live for public use then these values would most likely be hidden from the user and the server would run on a dedicated IP address and port number.

Once the user has connected and been validated with the remote server, they will enter the main chat room. Figure 1.2 demonstrates the appearance of the chat room. Immediately the server will inform the client of all members currently in the chat room. These values will populate a list of connected users in the main application window. The user will see two text fields, the first will display the entire conversation and system messages (for example, a user joins or leaves) for the session of the user. The user will also

have a text window where they can type their own messages to the conversation window.

The user will also have the option to create a private message with individual members. To initiate a private message they will select a user from the user list and ‘double-click’ the item in the list. This will open a new chat window just for a conversation with that particular user. The user cannot open a private message window with him or her self. If a remote user establishes a private message and sends it to the user, the message will automatically be populated in the associated private message window. If there is currently no private message window open with that remote user, the application automatically opens it and displays the message.

 

Figure 1.1 - Client Login Screen

Figure 1.2 – Main Chat Window

 

3.2 Network Communication Design

 

The server application will listen for any new connections from client connections on port 1000. Any new client connections will be added to an internal stack of client connections. All client applications will only communicate to the server and not to other client computers. This ensures that a client system cannot show the remote address of a particular remote user and results in improved security against other users of the application.

Figure 1.3 shows the data flow of the application between the clients and server. Each client will have a two-way communication link (send and receive) with the server. The server is responsible for relaying any messages between clients. The server may also log any events and data to a local file on the server computer.

 

 

 

 

3.3 Server Application Overview

 

When the server application is launched, the listen port number can be specified as a parameter during execution of the program. If the port number is not specified then the application uses a default port number of 1000.

The server will run in a command window and have a text based menu system to navigate through the server commands. Figure 1.4 shows the initial text menu when the server application is run.

 

Figure 1.4 – Initial Server Application Menu

 

[1] Start server [2] Enable logging [3] Clear log file [4] View log file [5] View current users [x] Exit Enter option: _

 

Pressing ‘1’ starts the server listening on the designated port. If the server is listening the menu option will state ‘Stop server’ and will stop the server from listening and close all existing connections.

Pressing ‘2’ will make the server log all activities and traffic. The log will go to JMessenger.log for later debugging. If logging is currently enabled then the option will state ‘Disable logging’ and will stop logging each event.

Pressing ‘3’ will delete the log file on the server.

Pressing ‘4’ will show all the contents of the log file on screen.

Pressing ‘5’ will show a list of all currently connected users on screen.

Pressing ‘x’ will close any active connections and terminate the server application.

 

4.0 Implementation

 

4.1 Structure of the Server Application

The server application creates an instance of a menu thread class, a listen thread class monitoring new connections and a list of clients running in their own threads tracking incoming data from individual clients. Figure 1.5 shows the structure of the server application classes.

 

Figure 1.5 – Server Class Structure

        

 

JMessengerServer is the main application class that create an instance of the text menu, listen thread and stores the client threads. Each sub class uses action events to return data and user responses to the main class ready for processing.

CTextMenuThread displays the server menu options and reads the user response via the keyboard. This class calls the following action events defined in CMenuListener that are implemented in JMessengerServer:

• onServerRunning

o Used to start or stop the server from listening to new connections and relaying messages from connected users.

• onShutdown

o Shuts down the server application and exits back to the operating system.

• onLogging

o Used to enable or disable server logging.

• onLogFileClear

o Used when the user requests to clear the log file.

• onViewLogFile

o Used when the user requests to view the log file.

• onShowConnectedUsers

o Used when the user requests to view all connected users.

 

CListenThread listens for incoming connections from remote clients. The class listens for a connection for a 10^th