|
Chapter 4: System Implementation
|
<< Page
1
2
3
4
5
6
>> |
 4.1.
Introduction
The ISC system consists of tree primary
applications (or modules): the ISC Client
Application, the ISC Server Application, and the
ISC Administrative Application. The tree
applications are designed to perform specific
tasks in order to provide various means of
communication to authorised clients. In this
chapter, the implementation task of each
application will be discussed providing detailed
information on how the system modules were
implemented to meet system requirements. In
addition, the chapter discusses the problems
encountered during the implementation process.
4.2.
Stages of Development
During
development of the system various stages
involved, each of which is explained in the
following sections.
4.2.1.
Stage One: Authentication
This stage
involved developing a system that enables
registered clients to attempt to sign-on by
providing a logon screen-name along with a
matching passcode. However, the system developed
was unable to alert clients with the sign-on
process status. In other words, if the sign-on
process was unsuccessful because the provided
passcode was incorrect, the client application
could only display “authentication failed”
without reasoning such a result that can be due
to other reasons, e.g. the application could not
establish a communication channel with the
server or the server is overloaded, and
therefore, refused the connection. Furthermore,
the server application could not provide clients
any type of service other than the
authentication process.
Figure 4.1: Stage one: authentication.
4.2.2.
Stage Two: Message Broadcasting
At this stage,
the system improved as the ISC server was able
to authenticate clients and broadcast their
messages to their online peers. In addition, the
client application provided clients with the
sign-on process status by using some ISC
commands, which are sent from the server.
Figure 4.2: Stage two: message broadcasting –
server screenshot.
Figure 4.3: Stage two: message broadcasting –
client screenshot.
However, the
client application was not able to list the
current online clients.
4.2.3.
Stage Three: Private Sessions
The third stage of the implementation task had
made a significant improvement to the system.
The system is now capable of authenticating
clients, broadcasting clients’ public messages,
updating online users-list, as well as,
establishing private sessions amongst clients
where they can exchange messages in privacy. The
client application allows clients to sign-off
the system by using a special ISC command.
Figure 4.4: Stage three: private sessions –
client screenshot.
However, private sessions are established
without authorisation from the other party who
may not wish to establish a private session. In
addition, the system still cannot provide
clients services other than public messages and
private messages exchange service.
Figure 4.5: Stage three: private sessions –
client screenshot.
Figure 4.6: Stage three: private sessions –
server screenshot.
4.2.4.
Stage Four: Message Exchange Subsystem
The fourth stage of the system implementation
completes the implementation of the ISC Message
Exchange Subsystem. This is achieved as the both
of client and server applications are capable of
authenticating clients, exchanging public
messages amongst online users, and establishing
private sessions between clients. This stage
improves the system developed during the earlier
stage as it requires an authorisation of the
other party in order to establish a private
session between two clients. The task was
accomplished by defining ISC commands that
represent other party’s decision whether or not
to approve the private session request.
Figure 4.7: Stage four: Message Exchange
Subsystem – client screenshot.
Figure 4.8: Stage four: Message Exchange
Subsystem – server screenshot.
4.2.5.
Stage Five: File Transfer
As the fourth stage implemented the ISC Message
Exchange Subsystem that provides clients to
exchange public messages, as well as, private
ones, this stage focused on implementing a
system that is capable of providing the ISC file
transfer service to online clients. Hence, the
fifth stage developed a system that enables
clients to share files amongst each other.
Figure 4.9: Stage four: File Transfer Subsystem
– client screenshot.
Figure 4.10: Stage four: File Transfer Subsystem
– server screenshot.
4.3.
ISC Server Application
The ISC server is a multi-purpose server that is
capable of providing various communication
services to its registered clients, including
message exchange, file transfer, and voice
conferencing. In addition, the application
implements a multi-threaded environment that is
able to provide its services to multiple clients
simultaneously. Note that a full coding of
the server application is provided in Appendix
A.
4.3.1.
Server Services
The ISC Server is the heart of the ISC system
where all clients of the system interact with
each other through it. All of clients’ messages,
including public and private messages, and
requests are served by this application. Hence,
it acts as a link between online clients to
provide them three reliable, efficient means of
communication: message exchange, file transfer,
and voice conferencing. Despite the fact that
the primary objective of the application is to
broadcast clients’ public messages to other
online clients and to forward clients’ private
messages to the appropriate client application,
it also serves clients’ ISC commands which plays
a crucial role for establishing file transfer
and voice conferencing sessions.
In addition, it performs other tasks such as the
authentication process. Furthermore, each of
the services provided by the server application
is discussed in more details below.
4.3.1.1.
Multi-threaded Environment
As mentioned earlier, the ISC server provides a
multi-threaded environment to handle multiple
clients simultaneously. Once the server starts
up, it opens a ServerSocket and listens
to a specific port waiting for clients’
connections. As soon as a client attempts to
establish a communication channel with the
server, the latter launches a new thread to
handle clients’ messages and requests. This
thread is defined in class “SysHandler”,
as shown below.
|
ServerSocket server = new
ServerSocket(port);
System.out.println(">> Server has
started.\n\n" +
">> Listening to port [" + port +
"]...");
while (true) {
Socket client =
server.accept();
System.out.println(">>
Connecting [" +
client.getInetAddress() + "]...");
SysHandler handler = new
SysHandler(client);
handler.start();
}//close while
|
Figure 4.11: Multi-threaded environment.
The “SysHandler” class provides a
concurrent environment that is able to serve
clients simultaneously and keep track of each
connected client. In other words, each client is
assigned with a separate thread to handle
his/her requests. However, access to ISC
services is only granted to authenticated
clients. Consequently, once a new thread is
started, it requires the client to provide a
valid screen-name along with a passcode to
complete the authentication process. Hence,
access is granted according to the result of the
authentication process, i.e. if the process was
positively carried out, client is granted a full
access to the ISC services, otherwise, access
will be denied, the communication channel will
be closed, and consequently, the thread is
terminated.
|
//first start the authentication
process
switch( signon() ){
case 1 : //@connection was
accepted
msg = new
Message("ISC-CONNECTION-ACCEPTED");
o.writeObject(msg);
System.out.println(">>
[" + client.getInetAddress() + "] is
connected");
System.out.println("");
Broadcast broadcast =
new Broadcast(client, handler,
currentUser, usersList);
broadcast.start();
break;
case -1 : //@user is already
signed on
msg = new
Message("ISC-CONNECTION-SIGNEDON");
o.writeObject(msg);
System.out.println(">> User is
already signed on!\n" +
">>
[" + client.getInetAddress() + "] is
not connected.");
break;
case 0 : //@invalid detials
msg = new
Message("ISC-CONNECTION-REJECTED");
o.writeObject(msg);
System.out.println(">>
Authentication failed!\n" +
">>
[" + client.getInetAddress() + "] is
not connected.");
break;
}//close switch
|
Figure 4.12: SysHandler” class.
4.3.1.2.
Authentication Process
The ISC system provides some security measures
such as client authentication. This process
takes place before granting clients the access
to the ISC services. However, the server
application performs a critical task of the
authentication process. The process starts as
soon as a client attempts to sign-on the system.
The server then listens through the port waiting
for client’s details, including client’s
screen-name and passcode. Once the server
receives client’s details, it attempts to open
the “clients’ database” in order to
verify the provided details against clients
profiles, which are stored in the database. It
is worth mentioning that the application reads
clients’ profiles from the database using
RandomAccessFile, as shown below.
|
//open database
RandomAccessFile database = new
RandomAccessFile("ISCDatabase.db",
"rw");
//get client's details
…
//Initialize required variables
long recordOffset;
int recordCount;
String screenName;
String passcode;
//verification process
do{
database.seek(recordOffset);
recordCount =
database.readInt();
screenName =
database.readUTF();
passcode =
database.readUTF();
//verify
…
}while(recordCount != -1); |
Figure 4.13: Authentication process using
RandomAccessFile.
|
//verify
if (
screenName.equals(user.get_screen_name())
&&
passcode.equals(user.get_passcode())
){
//check if the user is
already signed on
if (
usersList.users.contains(user.get_screen_name())){
return -1;
}//close if
currentUser = new
UserDetails(user, client);
handler.addUser(currentUser);
Users.addUser((String)currentUser.get_screen_name());
database.close();
return 1;
}//close if
else{
recordOffset =
database.getFilePointer();
}//close else |
Figure 4.14: Verification process.
4.3.1.3.
Message Exchange
As mentioned earlier, one of the primary
objectives of the ISC server is to handle
clients’ messages. The message exchange service
of the ISC system can only be accessed by
authenticated clients using a separate Java
thread, which is defined in the “Broadcast”
class. This service involves handling both types
of clients’ messages: public and private
messages. Each of which should be treated in a
different manner in order to deliver clients’
messages to the appropriate client(s). Hence,
the “Broadcast” class provides a
mechanism to deliver different type of messages
by encapsulating clients’ messages within Java
objects that can be classified to be either a
public or private message via a special flag.
Public and private messages can be created by
initiating an instance of the “Message”
class. The following discussion explains the
mechanism of handling both types of messages.
However, prior discussing how the server handles
clients’ messages, it is important to look at
how the server keeps track of all online
clients.
4.3.1.3.1.
Users List Handling
To keep track of all online clients, a class
that is named “UserHandler” is dedicated
to store clients’ details in a Java vector.
Therefore, once a client is successfully
authenticated, the server updates its vector by
adding the new client’s details, including
his/her socket that represents the communication
channel between the server and the client.
However, once a client signs-off the system or
is not reached, his/her details will be removed
from the vector.
4.3.1.3.2.
Public Messages Handling
A Public message represents a client message
that is to be broadcasted to all online clients.
A message can be classified as public by sitting
the “isPublic” flag to true. Once the
server receives a message that is set as a
public message, it broadcast it to all online
clients. The process of broadcasting public
messages is accomplished by implementing a
broadcast method, as shown below.
|
//broadcast public message
synchronized (handler) {
Iterator iterator =
handler.getList();
UserDetails current;
while ( iterator.hasNext()
){
try{
current =
(UserDetails)iterator.next();
ObjectOutputStream o = new
ObjectOutputStream
(
current.getSocket().getOutputStream
());
o.writeObject(message);
}//close try
catch ( Exception e
){
…
}//close catch
}//close while
}//close synchronized |
Figure 4.15: Broadcast public messages process.
4.3.1.3.3.
Private Messages Handling
Private messages can be created by initiating an
instance of the “Message” class and
sitting the “isPublic” flag to false.
They represent those messages that are sent from
private sessions. Therefore, they are initiated
to be delivered to the appropriate clients that
are involved within a private session. This is
achieved with the help of the ISC Client
Application as it defines the other party’s
screen-name, who is expected to receive the
message, prior sending the message to the
server. Once a private message is received, the
server attempts to deliver the message to the
clients defined within that message. Hence, the
message will be sent to both of the sender and
the receiver.
|
//broadcast public message
synchronized (handler) {
Iterator iterator =
handler.getList();
UserDetails current;
while ( iterator.hasNext()
){
try{
current =
(UserDetails)iterator.next();
//is it just
a private message? then send to both
parties
if (
temp.equals("PRIVATE") ){
if (
current.get_screen_name().equals(message.to)
||
current.get_screen_name().equals(message.from)
){
ObjectOutputStream
o = new ObjectOutputStream
(
current.getSocket().getOutputStream
());
o.writeObject(message);
}//close if
}//close if
//then it is
either a private request or a reply
for a private request
else{
…
}//close
else
}//close try
catch ( Exception e
){
…
}//close catch
}//close while
}//close synchronized |
Figure 4.16: Private messages handling.
<< Page
1
2
3
4
5
6
>> |
