ECSE 489 – Telecom. Network Lab – Winter 2014 Bénédicte Leonard-Cannon, 260377592

Friday, April 11, 2014 Payom Meshgin, 260431193

Final Project: Extensions to Chat

Client TABLE OF CONTENTS

1 Introduction ............................................................................................................................................................. 2

2 Work Accomplished .............................................................................................................................................. 2

2.1 SSL ...................................................................................................................................................................... 4

2.2 User Interface Modifications .................................................................................................................... 4

2.2.1 Sending a file ......................................................................................................................................... 5

2.2.2 Receiving a file ...................................................................................................................................... 6

2.3 Sending and Receiving Files ..................................................................................................................... 6

2.4 Database Storage and Retrieval .............................................................................................................. 6

3 Design decisions ..................................................................................................................................................... 7

3.1.1 User Interface ........................................................................................................................................ 7

3.1.2 File encoding and decoding scheme ........................................................................................... 8

3.1.3 Database storage and retrieval ...................................................................................................... 8

3.2 Challenges ....................................................................................................................................................... 8

3.2.1 SSL ............................................................................................................................................................. 8

3.2.2 File sharing ............................................................................................................................................. 9

4 Results ........................................................................................................................................................................ 9

4.1.1 SSL ............................................................................................................................................................. 9

4.1.2 User Interface ..................................................................................................................................... 10

4.1.3 Database storage and retrieval ................................................................................................... 11

5 Aspects of Network Experimentation .......................................................................................................... 15

6 Conclusion ............................................................................................................................................................. 15

7 References ............................................................................................................................................................. 15

2

1 INTRODUCTION

The objective of this experiment is to extend the basic chat client designed in Lab 3 by

implementing additional features and modifying the server to reflect these changes. First, we

establish secure socket layer (SSL) security over the client-server connection to encrypt the

messages between the server and the client, and hence protect usernames, passwords and

server from external attackers. Next, we modify the client and the server to provide file sharing

capabilities between users, as well as database file storage.

In this report, we discuss the work accomplished, the design decisions made in response to the

challenges we encountered, the results obtained and the aspects of network experimentation.

2 WORK ACCOMPLISHED

This sections summarizes the extensions to the chat client and server that we successfully

developed. The final client architecture is displayed on Figure 1.

3

Figure 1: UML class diagram of the chat client

4

2.1 SSL

The server and client were modified to communicate over the network through an SSL socket

rather than the Server socket that was employed in Lab 3. SSL is used to protect data being

transferred over the public internet from malicious users by sending data over an encrypted

communication channel [1].

First, we created an SSL certificate using the Java Keytool program to allow the client and the

server to establish a trusted SSL connection. This certificate contains a “key pair as well as

verified identification information” that is used by the client to verify the identity and trustability

of the server and establish a handshake with the latter [1].

Next, we set the Java system properties required to locate the certificate and set its password on

both the client and the server side. Then, we created an SSL socket at the server’s address and

port using an SSLSocketFactory.

Ideally, creating the certificate and establishing a handshake between the client and the server

should have been sufficient to establish a communication channel. However, both the client and

the server were initially relying on the isAvailable() method to check for incoming bytes. Even

though the isAvailable() method functions with regular Server sockets, it is incompatible with

SSL sockets because the amount of encrypted bytes received (and available) are of

undetermined length. To counteract this problem, we developed a new algorithm relying on the

SSL socket input stream to detect incoming bytes. Simply put, our algorithm reads a sequence

of incoming bytes from the input stream, stores them in a buffer and blocks until 12 bytes have

been received. Since all packet headers are of length 12 bytes, the algorithm blocks until a

packet header has been received, providing similar functionality as isAvailable() and hence

ensuring the proper behaviour of the connection between the server and the client.

2.2 USER INTERFACE MODIFICATIONS

For the client to provide file sharing capabilities, the user interface designed in the previous

experiment was reused and enhanced. As in Lab 3, the user interacts with the client through the

command prompt, extended with new capabilities.

5

2.2.1 Sending a file

To allow the user to send a file to another user, a new option, "2. Send file", was added to the

logged in menu, displayed on Figure 2. This option is selected by typing "2" in the Java console.

The terminal then prompts the user to place the file he wants to transmit in the "files" directory

located in the program's main directory, and to type in the corresponding file name (e.g.

myFile.txt). The interface also advises the user not to input a filename that contains a comma,

since the client-server communication protocol uses this character as a delimiter for a

StringTokenizer in some of its message parsing procedures including the Store File messages. In

the event that a comma is inputted, the program reprints the instructions and waits for user

input as long as the requirement is not fulfilled. The user interface also notifies the user that the

file size must range between 1 byte and 64kB to respect the limitations of the server (see section

3.2.2 for more details). If the user does not respect this requirement, or if the file is not found,

then the file is not transmitted and the program returns to the logged in menu. On the other

hand, when all requirements are met, the interface prompts the user to enter a recipient name

that does not contain a comma. Here again, the client prompts the user for a recipient name as

long as it is not valid. Finally, with all required information in hand, the program sends the file

and its metadata over the network and the logged in menu is displayed back on the terminal.

Moreover, the client displays the outcome (success or failure) of the transfer.

Figure 2: Logged in menu interface

6

2.2.2 Receiving a file

When the user logs in, the system automatically polls the server for a file having this user as the

recipient at a rate of one query every ten seconds. When a file is transferred, it is placed in an

"incoming" directory and the message "user x has sent you the file y" is shown on the terminal.

2.3 SENDING AND RECEIVING FILES

On the server side, the functionality is extended as it stores the files sent from the client,

wrapped around a Message object, into an SQLite database. However, since files are generally

encoded in binary instead of plain text, the Message object format must be modified to permit

non-textual data. Instead, we employ a different approach to handling files.

In this design, all files are encoded as hexadecimal strings, so as to reuse the same Message

structure associated to all other message types. Hence, the file contents must be converted to

an equivalent plain-text format, which can then be directly added in the payload of a Message

object. Unfortunately, the main limitation involving this process is that file contents, once

converted to string format, become twice as large in size as the contents of the actual file. As

pictured in Figure 3 below, each byte in the binary file is converted to a pair of equivalent

characters, which are then stored in two bytes.

Figure 3 : Binary file content to hex string mapping

2.4 DATABASE STORAGE AND RETRIEVAL

All files must be stored in some fashion in the database. In our particular case, this feature is

implemented through the use of binary large objects, or BLOBs that can be stored directly in the

database. Hence, upon receiving a file from the client, the file content, as well as certain

metadata such as the filename and the identities of the sender and recipient, is stored directly as

an entry in a dedicated table in the database intended for files (aptly called “files”). Thus,

7

whenever the client queries the server for new files, the server in turn queries the database for a

file whose recipient matches the username of the connected client. In the event of a match, the

associated file content (including meta data such as sender, recipient and filename) is packaged

in a message towards the client, which reconstructs the file from the result of the initial query.

3 DESIGN DECISIONS

The design process that was followed throughout the project was heavily inspired from the way

the tasks were split between the team members. The workload was initially split up in two

distinct sections (enabling SSL, implementing file transfer) to allow the work to be done in

parallel. Then, each section were to be developed iteratively (from one side of the connection to

the other). However, this process was discarded after it was determined that the work could be

done just as quickly by the members working simultaneously on the same feature, but on

opposite ends of the problem (where one person implements server-side aspects and the other

works on the client-side component of the feature).

This section outlines the design decisions taken and the challenges encountered during the

design and development of our system, as well as the solutions that were found to address

these problems.

3.1.1 User Interface

Minor design decisions were made with respect to the user interface since most of it was

designed during Lab 3. First, we pondered on the best way for a user to select a file for transfer.

We considered two alternatives, both of which involved inputting the file name on the

command prompt. One option that we considered was to provide a dedicated folder within the

program directory in which the user can place any file he wishes to transfer then input the

filename in the terminal. Another possibility that we considered was to request the user to input

the absolute path of a file stored anywhere in memory. Since absolute paths can be quite

tedious to type in on a console, we settled for the first option providing better usability.

Initially, a single folder called “files” was created for the purpose of file sharing and was used

both for sending and receiving files. While we were conducting file-sharing tests, we quickly

realized that whenever an incoming file shared the same name as a file currently located it the

8

“files” folder, the current file was overwritten. To prevent this undesired behaviour, we created a

second folder, called “incoming”, dedicated exclusively to file reception.

3.1.2 File encoding and decoding scheme

There are several valid ways to transfer binary file data between the client and the server. For

example, a custom message object can be formed such that the file content is streamed as a

Byte array. Similarly, the existing implementation of the Message object can be modified to

support byte arrays in the payload instead of a String object. In the end, it was decided that the

file content was to be inserted as a String within a Message object. While this method effectively

reduces the maximum file size to about half of the original (due to the inflating effect described

in section 2.3), it was much simpler to implement since virtually none of the existing code would

need to be modified to support sending files. Hence, code reusability was prioritized over

preserving the design scope (in this case, allowing the transfer of files above 128 kB).

3.1.3 Database storage and retrieval

Again, there were multiple solutions considered for storing file content on the server. The

original design, which was implemented in the end, involved storing the file into a table entry in

the database, with the file content being stored in a blob. Other alternatives to this approach

included storing the file in the file system of the server and storing the filepath in the database,

or having the file be stored on a remote web server. We ended up using the initial idea, since

the maximum file size is quite manageable as a blob within a database and that executing query

using hex encoded strings as parameter is more convenient than the other alternative options.

3.2 CHALLENGES

3.2.1 SSL

The first challenge that we encountered was related to the isAvailable() method. After

establishing the SSL connection between the client and the server, we initially were unable to

successfully share messages between the two. We eventually realized that the isAvailable()

method was incompatible with SSL sockets, since it always returned 0 regardless of the actual

9

availability of the values in the incoming buffer. To address this issue, we browsed through the

list of methods providing SLL socket reading capabilities and settled for an InputStream-based

solution, which allows for blocking execution as long as the expected packet length has not

been reached.

3.2.2 File sharing

We encountered a problem when attempting to transmit a file of size close to 128kB, the

maximum inflated packet size allowed by the server; attempting to transfer relatively large files

(that are nonetheless respecting the 128kB limit) results in the server rejecting the incoming

packet. This behaviour is caused by the SSL encryption process that significantly increases the

size of each byte -and thus each packet- transmitted over the channel. In other words,

encrypting a file of size smaller than 128kB can potentially produce a packet of size larger than

256kB which the server cannot handle. Unfortunately, we did not fix this problem since we

couldn’t probe into the encryption process and measure the size of an encrypted byte. In spite

of that, we alleviated the problem by limiting file transfers to 64kB.

4 RESULTS

We successfully managed to extend the chat client and server from Lab 3 to provide SSL security

as well as file sharing capabilities. To achieve this level of functionality, we tested each of the

modules to ensure that their individual requirements were met, as well as the system as a whole.

4.1.1 SSL

We began by verifying that the SSL connection between the client and the server was properly

established. In order to do so, we used the OpenSSL software to listen to the port and address

used by the SSL socket. Based on the program output, shown on Figure 4, we confirm that the

connection was properly set up.

10

Figure 4 : OpenSSL handshake confirmation

4.1.2 User Interface

To test the new functionality of the user interface, a series of high-level tests were performed.

More precisely, we navigated through the different possible scenarios associated with the “Send

file” command and verified that the interface was behaving as expected. First, we ran a series of

tests pertaining to file selection, as shown on Table 1. Next, we tested the behaviour of the

interface in response to valid and invalid recipient names inputted by a user, as displayed on

Table 2. Finally, we ensured that the user receives an appropriate notification whenever he

11

receives a file from the server. As expected, each test induced appropriate response of the user

interface.

Table 1 : Interface response to different file inputs

Test name Interface response Test

result

1. Send an unexisting file “Error. File not found.” Success

2. Send an empty file “Error. File is empty.” Success

3. Send a file of size greater

than 64kB “Error. File too big.” Success

4. Send a file whose filename

contains a comma

“What is the file name?” is repeated as long as a

comma is inputted in the filename Success

5. Send a valid file “Your file has been sent.” Success

Table 2 : Interface response to diverse recipient inputs

Test name Interface response Test

result

1. Input an empty recipient “To whom do you want to send the file?” is

repeated as long as the field is empty Success

2. Input an unexisting

recipient "ERROR: Recipient does not exist." Success

3. Input a recipient whose

name contains a comma

“To whom do you want to send the file?” is

repeated as long as a comma is inputted in the

name

Success

4. Input a valid recipient “Your file has been sent.” Success

4.1.3 Database storage and retrieval

In order to test the SQL commands ran on the SQLite database, as well as to verify that file

transfers are behaving as expected, we used a tool called SQLite Manager, an extension for

Mozilla Firefox. First, we verified the validity of the new SQL commands that were added as part

of the file transfer feature. In particular, these commands are associated with adding entries to

12

the files table, finding entries where the recipient field matches a certain name and deleting

such entries from the table.

As an integration test, we run the server and client applications and observe the state of the

database as various database interactions are made. In Figure 5, the client logs in under the

username aaa and sends the file banana.jpg to user bbb. The application responds with a

successful “Your file has been sent.” message, while the server prints to the console the

contents of the file as a hex string. Then, as shown in Figure 6, the database is updated with a

new entry in the “files” table: the same banana.jpg file intended for user bbb. Within the SQLite

Manager tool, we save the contents of the blob to a file to verify that the banana.jpg has been

successfully stored in the database, which is indeed the case by observing Figure 7. Then, back

inside the client, we log in under the user bbb and verify that the file does transfer to the

“incoming” folder (Figure 8). Finally, we check that the entry for banana.jpg is deleted after

successful transfer to the client (see Figure 9).

Figure 5: File encoded as a hexadecimal string received on the server side (left), with client

transferring said file (right)

13

Figure 6: File table contents after storing a .png image in the database

Figure 7: Verification of file correctly being stored in the database

14

Figure 8: Reconstructed .png file received in the incoming folder on the client side

Figure 9: File table contents after discarding the .png image from the database

15

5 ASPECTS OF NETWORK EXPERIMENTATION

The primary aspect of network experimentation present in this project is programming. As such,

this experiment allowed us to extend our knowledge of SSL socket programming, database

management, as well as file transfer protocols.

6 CONCLUSION

In summary, we successfully extended the chat client and server by using SSL encrypted

connections as well as file sharing capabilities. More precisely, we established a secure

encrypted communication channel between the server and the client through an SSL socket

connection. In addition, we extended the client and server to allow users to send and receive

files to/from each other over the public internet. We also enhanced the client user interface to

allow a user to send a file on demand, as well as receive a notification when a file is received.

Several enhancements could be made to our system to improve its functionality. First, we could

improve the system usability by replacing the command prompt interface by a graphical user

interface (GUI). Such an interface could be used to display each function, such as chatting and

file sharing, on individual windows, allowing the user to multitask. Moreover, it would be

interesting to enhance the chat system for multi-user communication, so that chat groups can

be created. Finally, it would be useful to reduce the file-size limitations that are currently set by

the server, to allow sharing of larger files such as high-resolution images or short videos.

7 REFERENCES

[1] “How SSL works.” Internet: http://www.symantec.com/page.jsp?id=how-ssl-works, [Apr. 9,

2014].