ECSE 489 Telecom.

Network Lab Winter 2014 Bndicte 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 servers 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
couldnt 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].