Aaron Christopher

traderainSoftware and s/w Development

Aug 15, 2012 (4 years and 10 months ago)

349 views

Aaron Christopher

CSC515 Project


The
Proposal


The project will be an exercise in developing an object oriented system following a sequence of analysis, design
and implementation. UML structural and behavioral models will be given along with the fully
realized system
in Java.


The full master’s project consists of a sourceforge like system that allows software developers to share code and
documentation. It goes one step farther though and also allows developers to provide a virtual appliance
containin
g their software so that other users of the system can run that software instantly on their own PCs in a
platform independent way utilizing VNC. Users of the system can also start collaborative sessions where they
access a live software module simultaneou
sly with other users and can communicate using instant messages.
This is achieved using a custom (collaborative) VNC client built for that purpose. This system is intended to
facilitate platform independent live expert collaboration and online training.


The software system that will be presented for this class is a piece/subset of my master’s project called
‘Collaboration Server’. It is the part of the main project that handles client logins/authentication, the
management of the software module databas
e, the management of single user live session, the management of
collaborative live sessions and text chat.

The system presented here is about 20% of the total project.


The Project


Project
Downloads


While documentation describing the major functionalit
ies of the system are provided in the
remainder of the
document below, the complete UML model
can be downloaded
here
. It is a NetBeans project and can be
opened using version 5.5 or later with the UML modeling p
lug
-
ins installed. Downloading and installing the
UML modeling plug
-
ins can be easily done in the
NetBeans
IDE using
the update center wizard.


http://www.netbeans.org/communi
ty/releases/55/uml
-
download.html


The project source can be browsed
here

or an archive downloaded
here
.


The PowerPoint presentation used in class:
presentation.ppt

It contai
ns many more images from the actual
UML model than the documentation below.


Project
Overview


The collaboration server is a multithread application written in Java using blocking TCP sockets from the
standard java.net package. Communication is conducted
between the server and its clients via message passing
using serialized objects. The server’s principle functionalities are the following:


1.

Client Authentication

2.

File Transfers

3.

Database Interaction

4.

Text Chat

5.

Session Control




Client Authentication


The
server allows for modes of client logins: regular and open. Users of the system are uniquely identified by
their handles (user name).


When operating under regular mode, the server requires that clients be registered with the server prior to the
login.
The server stores the client’s information in its database and uses that information to authenticate the
login. The server stores the following information: the client’s handle (user name), password, full first and last
name, geographic location, e
-
mail
and telephone number.


When operating under open mode, the server allows clients to log in without first being registered in addition to
handling logins by registered users. A client logging in under open mode is required to select a unique handle
and pro
vide a full first and last name, geographic location, e
-
mail and phone number before connecting to the
server. If the handle selected by the client is already in use be either another using participating in an open
login or a registered user, the login wi
ll be rejected by the server. The reason for the rejection will be reported
to the client who may then select a different handle and try to log in again.


Overview of Client Authentication Process







When a new CollaborationServer object has been ins
tantiated and called to action, one of the first things it does
is create and run a new ServerWorker thread. That thread encapsulates the main listening socket of the server to
respond to incoming connections.


When a remote socket connects to the server’
s server socket, the ServerWorker thread creates a
ClientAuthenticaionWorker thread to handle the rest of the authentication. This strategy immediately frees the
ServerWorker thread to continue listening for more connections while the new thread handles t
he authentication
asynchronously.


The ClientAuthenticationWorker thread reads the login information provided by the client. It calls
registerHandle() method of the ServerWorker thread to make sure that the handle provided by the client is
unique and avai
lable for use. If the registerHandle() method inicates that the handle is can not be used, a
message communicating the reason for the failure is sent back to the client and connection is closed. If the
handle is available, the call to registerHandle() re
serves that handle on the system and indicates success to the
ClientAuthenticationWorker thread.


The ClientAuthenticationWorker thread, upon receiving the success message, constructs a new Client object
and calls the addClient() method on the ServerWorker

thread passing the newly constructed Client object as a
parameter.


The ServerWorker thread then calls registerClient() method on the CollaborationServer. That method call
completes the client connection process after constructing a new ClientWorker thre
ad for the client. That thread
is then used to handle all IO for the client asynchronously from this point forward. During this time it is also
ensured that the client’s home directory on the server exists and is ready for use.


File Transfers


Every cli
ent has its own home directory on the server that it can upload files to and download from. The home
directory is named using the client’s handle and its purpose is to allow the client to upload files that can be
accessed by the live software installed on

the system. It also allows any output from the live modules to be
copied to the client’s home directory where that data can then be downloaded to the client’s local machine.
Every live software module should be configured to access a shared NFS volume w
here the home directories
are stored.


Each software module in the catalog can potentially have three files associated with it: a source code archive, a
documentation archive and a virtual appliance archive. The client is able to download any of these fi
les, if they
exist, to its local machine.


File Transfer Mechanism Overview




The LocalVolumeInterface is responsible for facilitating file IO on the server. It provides methods that allow
file streams to be obtained for any of the module files associat
ed with a software module that is listed in the
catalog. The current version of the software does not support the uploading or downloading of directory trees in
the client’s home directory


only single files located in the root of the home directory.


Th
e FileTransferController is the focal point of this part of the system. It process FileTransferMessages that are
passed to and from each client during uploads and downloads.


Uploads


The systems only services uploads that occur when a client transfers fi
les to its home directory. When an initial
FileTransferMessage is received by the server, a FileUploadThread is created that handles the upload from that
point on. The new thread is registered with the FileTransferController so that subsequent FileTransf
erMessages
that are revived for this file will be relayed to it.


When the upload is complete (the last FileTransferMessage has been processed) the FileUploadThread calls the
uploadComplete() methods of its FileTransferController and stops. The FileTransf
erController does some clean
up and removes that thread from its list of active file transfers.


Downloads from Client’s Home Directory


The client sends a FileDownloadRequestMessage to the server. The downloadClientFile() method is called on
the server’s

FileTransferController. That method obtains an InputStream for that file from the
LocalVolumeInterface and uses it to start a new FileDownloadThread.


The new FileDownloadThread is started and resistered with the FileTransferController. The thread sends

the
file to the client one FileTransferMessage at a time. When the last FileTransferMessage has been sent, the
thread calls the downloadComplete() method of its FileTransferController. The FileTransferController cleans
up and removes the download thread

from its list of active file transfers.


Module File Downloads


The server receives a ModuleFileDownloadRequestMessage from the client which is processed by the
FileTransferController. The method startModuleFileDownload() is called on the FileTransferCon
troller. The
module file request message contains the primary key of the software module and a flag specifiy wich module
file is to be downloaded. That method then uses the DatabaseInterface to resolve the database keys to the actual
file housed on the s
erver.


Once the file name has been receved the LocalVolumeInterface is used to obtain an InputStream for the file.
The InputStream is then used to start a new FileDownloadThread.


The new FileDownloadThread is started and resistered with the FileTransf
erController. The thread sends the
file to the client one FileTransferMessage at a time. When the last FileTransferMessage has been sent, the
thread calls the downloadComplete() method of its FileTransferController. The FileTransferController cleans
up
and removes the download thread from its list of active file transfers.


Database Interaction


The server uses an Apache Derby database to store its catalog of software modules and registered users.


Database Interaction Mechanism Overview




When a Col
laborationServer is first constructed, it tries to connect to its Derby database. All intereactions with
the database are done through the singleton DatabaseInterface. If the database connection can be established
the construction of the ColloborationSer
ver will fail.


Currently, the database contains two tables. One to store entries in the software module catalog, the other to
store registered users.


The DatabaseInterface has public methods getRegisteredUserList() and getApplicationModuleList() that
provided access to lists that contain all of the entries in the two corresponding tables. All database modification
is done through the DatabaseInterface. If recorded in and of the tables are added or removed using the provided
interface methods, the lis
ts are immediately updated. They always reflect the current state of the database and
provide a quick and convenient way for the records to be viewed.


Text Chat


When a group of users are connected to a collaborative session they have the capability to s
end text messages to
one another in a group chat room. Every collaborative session has a TextChatRoom associated with it and
every member of the session is automatically a member of the room.


Text Chat Mechanism Overview




The creator of a TextChatRoom

calls the openChatRoom() method on the ChatController. As of the current
implementation, a client may only belong to one chat room at a time. The ChatController maintains a map of
clients to chat rooms as well as a list of all open chat rooms.


When a

client is enrolled in a chat room, it calls that room’s enterRoom() method. The TextChatRoom registers
and then forwards the request to the TextChatController to finish the registration process and update the map of
clients to rooms.


When the server rec
eives a TextMessage from a client, the message is forwarded to the TextChatController for
processing. The controller uses its map to resolve the client object from which the message was sent to the chat
room that the client is a member of. The method for
wardToAll() is then called on the TextChatRoom object.
The method sends a copy of the text message to all of the members of the chat room including the original
sender. If the client receives the echoed copy of its message, it can be reasonably assured t
hat the message
reached the other members.


Whenever a client request it via a ChatRoomMemberListRequestMessage or a client leaves or enters a chat
room, a ChatRoomMemeberListMessage is sent to all of the other members currently in that room.


Session Co
ntrol


At the heart of the collaboration server is the ability for the client to access a live running version of a software
module and control it remotely. There are two kinds of sessions: direct and collaborative. Direct sessions allow
a single user to

take control of a live module and use it exclusively. A collaborative session allows several
users to all access the same live module simultaneously. Any client may start a collaborative session. The
client that starts a session is called the session m
aster and reserves administrative rights on that session as long
as it is active. Those rights include:



the ability to choose the pixel format used by the session



the ability to select which, if any, of the connected clients is allowed control the session

(when control is
disabled, a client may only view the session)



the ability to activate automatic remote screen synchronization or assert manual control


There are two kinds of collaborative sessions: public and private. Active public and private sessions

are listed
by the server and accessible by any client. The only difference is that private sessions are locked by a password
that is chosen by the session owner. Any client wishing to join a private session must supply the correct
password.


Session Con
trol Mechanism Overview




The SessionController maintains a map of each software module’s primary key to a Boolean value indicating
whether that module is in use by a direct or collaborative session. When a session using a live module, clearly
another s
ession should not be allowed to access it.


The SessionController is also responsible for servicing module list requests from clients. When such a request
occurs via a ModuleListRequestMessage, the SessionController builds a list of every software module
currently
in the catalog and sends that list to the requesting client. When the list is built (via a call to
handleSessionListRequest() on the SessionController) it captures the current state of the live modules (whether
they are busy or free). The clien
t will want to regularly request the list to keep its view of the server’s state as
accurate as possible.


Starting Direct Sessions




When a client wishes to start a new direct session, it sends an instance of StartSingleUserSessionMessage to the
server.

The message contains the session ID (primary key) of the live module. The handler makes sure that the
module is available for use. If the module is busy a ModuleBusyMessage is sent back to the client. If there are
too many sessions being serviced by t
he server, a TooManySessionsMessage is sent back to the client.


If the module is available, the server generates a module key for the session. A module key is a string of bytes
used as a guard to prevent unauthorized clients from connecting to the live m
odules using VNC directly. The
server provides the session key to clients that have properly requested and been granted access to a specific live
module.


Once a session key has been generated, and a new instance of the multiplexing VNC server has been cr
eated
and attached to the live module, a SessionReadyMessage is sent back to the client. The message tells the client
how to connect to the live module by providing a port number and session key.


If a module was listed as available but the server could

not establish a connection to it due to a failure, a
SessionUnreachableMessage is sent to the client.


Starting Collaborative Sessions


When a user wishes to start a new collaborative session, it sends an instance of
StartCollaborativeSessionMessage to th
e server. The message contains the session ID (primary key) of the live
module. If the client wants to create this session to be a private session, is sets the privateSession flag of the
StartCollaborativeSessionMessage to true and provides a password fo
r the session. The handler makes sure that
the module is available for use. If the module is busy a ModuleBusyMessage is sent back to the client. If there
are too many sessions being serviced by the server, a TooManySessionsMessage is sent back to the c
lient.


If the module is available, the server generates a module key for the session. A module key is a string of bytes
used as a guard to prevent unauthorized clients from connecting to the live modules using VNC directly. The
server provides the sessi
on key to clients that have properly requested and been granted access to a specific live
module.


Once a session key has been generated, and a new instance of the multiplexing VNC server has been created
and attached to the live module, a SessionReadyMess
age is sent back to the client. The message tells the client
how to connect to the live module by providing a port number and session key. A new TextChatRoom is
created for the new session and the session owner is registered as its first member.


If a
module was listed as available but the server could not establish a connection to it due to a failure, a
SessionUnreachableMessage is sent to the client.


Joining a Collaborative Session




A client joins a collaborative session by send an instance of Joi
nCollaborativeSession message to the server.
The message is process by the SessionController who verifies the information contained on the message. It
makes sure the session is still and checks the password in the case of collaborative sessions. If the
client should
be granted access, an instance of SessionReadyMessage is sent to the client providing the session’s key and
port.


If session access should not be granted, an instance of SessionAccessDeniedMessage is sent back to the client.
The message has

text field that can, if appropriate, include a reason for the denial.


Leaving a Collaborative Session




When a client wishes to the leave a collaborative session, it sends an instance of
LeaveCollaborativeSessionMessage to the server. The message is p
rocessed by the SessionController via a call
to its leaveSession() method.


The leaveSession() method takes appropriate action based on the session type.


In the case of direct sessions, it shuts down the VNC multiplexer, disconnects it from the live mo
dule, and flags
the live module free in the catalog. For collaborative sessions it un
-
registers the client from the session as well
as the that session’s chat room.


If a session owner leaves a collaborative session, the entire session must end. All of t
he clients are
disconnected, the chat room is shut down and appliance is freed.