This application consists of three main parts which are the client, server, and the game of SOS. The server ran on an Elastic Cloud 2 (EC2) instance with Amazon Web Services where I configured the Windows server and supporting software. This includes creating a database in MS SQL Server, creating the necessary users and assigning them to the database they can access. Mappings are set for the user which grants the necessary permissions. The firewall also needed to be configured to allow the appropriate ports access so clients could connect to the server (and the server could receive connections). Internet Information Services (IIS) was also configured so that the Java Network Launch Protocol (JNLP) MIME type was recognized by the web server so that the client could be launched using Java WebStart from a webpage.
Client-Server communication uses a server socket that listens for incoming connections. When a connection is accepted a new thread (ClientHandler) is spawned which handles communications with the client through a socket. Java’s ObjectInputStream and ObjectOutputStream are used in order to send and receive Java objects.
Threading is used on the client side to listen for messages from the server. On the server side each client connection is ran in its own thread and handled by a ClientHandler class.
Database access is handled by the server using Java Database Connectivity (JDBC) drivers. Any information retrieved from the database is sent back to the client using a data transfer object (DTO) and packaged as a games room message of the correct type.
The application allows users to chat in a main room or create their own chat rooms which can be public or private. Users are able to join any public room but the only way a user can join a private room is through an invite from an active participant. Files can be sent to users of a room. This is done by reading the file as bytes and sending the byte array along with the filename as a string to users in the room. Java’s FileOutputStream class is used to write the file to the recipient’s local machine if they chose to accept the file and saved it.
Users are able to manage their profile information, Figure 1. Which allows them to change certain information, including updating their password. The application uses a hash implementation using the password-based key derivation function 2 (PBKDF2) algorithm with HMAC and SHA1 (part of RSA public-key cryptography standards) for hashing user passwords and then storing the hash value in the database. When a hash is being created for a password the string is converted to a byte array and a salt is created using java.security.SecureRandom for the specified salt byte size. The PBKDF2 hash of the password is then computed by creating a password based encryption (PBE) key of variable-key-size PBE ciphers utilizing the users’ password, salt, number of iterations, and how many bytes the result should be. Javas secret key factory, part of the javax cryptography package, is then utilized to generate the secret key (hash of the password) for the PBE key specification. All relevant data is then placed into one string which takes the format of ‘iterations:salt:hash’ where the salt and hash is first converted to hexadecimal. The colons are critical as they are utilized for splitting the information when validating passwords.
Users are able to play the game of SOS, Figure 2, when they are in a room they have created. The first two members to join the game can play, as it’s a two player game. The game implements the MVC pattern, using SosController.java as the controller, GameView.java as the view and the ChatClient as the model for how to handle requests from the user to the server and vise versa. DTOs are used to transfer data between the clients through the server as well as for saving game states. The DTOs are Board, Player, PlayerMove, SavedSosComponents, ScoreCard, and Turn.
Users are able to save the contents of a chat session for later viewing and a facility to view and manage any saved chats is provided, Figure 3. Users can also save a games state to be continued at a later date and when loading a saved games both participants must be logged into the application. Game states are converted to XML using XStream to be stored in the database.
Validators are created by implementing my Validate interface and a separate class for each validator (i.e. NewRoomValidator.java) is created. This separates out the process of validating information entered into the GUI from the actual GUI code itself.
