; Tech Spec
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Tech Spec

VIEWS: 1 PAGES: 10

  • pg 1
									Technical Specification


     Chatrooms



   James Kennedy
      58406375
    Peter Farrelly
      58329320


       24th March 2011
Table of Contents
Introduction/Glossary                2

System Architecture                  3

High-Level Design                    4

Object-Models, Data Flow Diagram's   5

Problems and Resolutions             7

Installation Guide                   9
Introduction
We developed a chatroom desktop application, it can be used to get in touch with like
minded people by entering one of our topical rooms, if you meet somebody in one of the
rooms you want to talk to you can select them from a list of users and chat with them, if
somebody requests to talk to you, you will be notified and can accept or reject them, if you
accept you will be entered into a one on one chat with that person. From the main
chatroom tabs you can update your facebook status and even post new tweets! The first
time you click either button you will be asked to sign in and after that you can post all your
messages, there is also a share button which will inform your friends of chatrooms if you
are signed in. Our system uses the facebook and twitter API's to connect to each of them
and to send messages. Our system can be used by any device capable of running Java as
the entire system uses the Java VM.

The system architecture is structured in a way to allow users the freedom to access their
social networking sites and manage multiple private conversations with ease but protect
them from the inner working of the system. Our simplistic design ensures users will be
provided with a sophisticated, user friendly experience in using our system. The unique
aspects of our system will ensures user will retain the use of Chatrooms many times over.




Glossary
IP : Internet Protocol,
HTML : Hyper-text Markup Language,
API : Application Programming Interface,
GUI : Graphical User Interface,
Java VM : Java Virtual Machine,
Tweet : A status update on Twitter,
Thread : A programming object used for running multiple processes simultaneously,
Buffer : Section of memory used to store temporary data before it is moved on,
TCP : Transmission Control Protocol,
UDP : User Datagram Protocol,
Datagram : Basic transfer unit used in UDP.
System Architecture
This program operates within the Java VM because of its’ efficiency and its’ portability. We
have incorporated a fully Object Oriented design within and developed a layered system
which allows for a Server/Client model for connecting and a sender/receiver model within
each Client.

The chatroom object has an integrated user object as well as sending and receiving
threads so each user will be protected by layers of classes for a minimum chance of
something going wrong.

The social networking aspect of this program has been done with the Facebook Java API
and the Twitter4J Java API. These are incorporated in our system behind the user
interface so the user will only interact with the parts of the system that are required for
operation.
High-Level Design
Each user when joining a chatroom asks the server to check who’s in the chatroom and
receives back each active users IP address.

Each chatroom already designated has a specified port number.

A user is brought to the main port first to get the names and ports of every currently
operational chatroom.

Private chatrooms are created by inviting somebody in your current chatroom to chat, the
program agrees on a port to use on each side and two users can begin chatting. If one of
the users leave the chatroom closes on both sides.

When a person leaves a chatroom their IP address is removed from the list of users in that
chatroom, when they return their IP address is added again.

When a person leaves the program their IP address is deleted from all linked lists they are
associated with, the linked list of “chatters” will skip null values and tidy up nulls at the end
of the list.

If a user wants to post a message to facebook or twitter there is a button for that, if a user
has not already logged in they will be prompted to log in and re-directed to the appropriate
web page to do so. A user will have to give permission to chatrooms before it can post
onto their wall.

When you want to let your friends know about chatrooms, there is a button beside the
send button to do that, if you haven't already logged in you will be prompted to do so, if
you have been logged in already our pre constructed message will be posted to twitter and
facebook for you, it will also contain information about what chatroom you are currently
chatting in.

Each of our client applications has a list of Chatrooms, a chatroom consists of a name, a
port it operates on, a condition to say whether it is open or not, and a list of users for each
room. A user consists of a name, which is supplied at run time, and an IP address, which
corresponds to their computer.

Our application also has Receiver's and Updater's, these will be associated with whatever
chatrooms are open up to a maximum of 6, the receiver's all listen on the associated port
for their chatroom to catch all messages which are sent to the user, it then sends the data
to a file and signals another guiUpdater thread to update the screen, the Updater's also
signal the guiUpdater when a new user connects to the chatroom they are assigned to.
Together these three threads go a long way to make our program user friendly and
interactive.

Their will be a support website and an associated email address so users can download
the program and user manuals. Their will also be a troubleshooting section detailing
solutions to problems that may occur within the system.
                  Client Object-Model
  User                                        ButtonTab
                                              Component
                          GUI


Chatroom




                        Receiver             Updater




                  Server Object-Model
    User
                                Server GUI




  Chatroom




           Receiver       Accepter           Server
                                             Updater
User Open Chatroom




User Connecting
Problems and Resolutions
    Buffer receiving messages with extra data;

We had this problem when we switched from tcp to udp ports, we solved it by purging the
messages of all surplus data.

    Updating file when messages are received;

We had a problem with a FileWriter not updating the file when we said for it to, we
overcame this by flushing and closing the FileWriter after each write.

    Loading file when it is updated;

We created a thread in the client gui called guiUpdater to overcome this problem, it
receives signals from the receiver and updater when there is new data to be handled, it
then either updates the user list or updates the text on the screen.

    Showing list of users on each pane;

As with the previous problem we used the guiUpdater thread. After a user joins they get
added to the list model on the gui and it gets updated.

    Keeping an updated list of users for each open chatroom;

We associated an updater with each chatroom, these all had to have access to a list of
users for their assigned chatroom and be able to update that list when new users
connected.

    Closing sockets, re opening them, Bind Errors;

We just had to take care to make sure all our sockets were closed properly whenever we
were finished using them, also when connection errors occurred we had to handle them
such that they would close whatever open sockets there might be.

    Stopping Threads when closing chatroom windows;

We had to make sure we could effectively interrupt each thread associated with the given
chatroom when we tried to close it, not achieving this could lead to problems where a user
might try to re open said chatroom.

    Open each chatroom once only;

We used a simple condition variable to overcome this problem, if the chatroom is opened,
it gets set to true, when it is closed it gets set back to false, all values are default set to
false.
    Creating new public and private chatrooms;

Implementing this proved to be a greater problem than we envisaged, it would add too
much to the complexity of the program and take too much time to implement, we decided
to just implement one on one private chatrooms instead.

    Posting to Twitter

This turned out to be very confusing as the twitter API is somewhat undocumented with
various solutions to problems being untested and useless. With thorough testing we
eventually managed to get our program working with the twitter4j API and tweeting to the
right user.

    Posting to Facebook

Although this was not as problematic as the twitter API we had some trouble with session
keys which led to user posting to the wrong wall. However this was more a logic error on
our part and was fixed once we went over the code and isolated the problem.

    Creating Chatroom files

We encountered a problem when creating chatrooms that the files were being made and
used to fast so we had to implement a timer to wait until all chatrooms had been created
fully before continuing on with the program which used said chatroom.
Installation Guide
To use this program you must first download the program from the following website:
http://student.dcu.ie/~kennej27/chatroom/index.html

Download the latest zip folder and unzip it. It contains all the .class files needed to run the
program and all the .jars required as well. The class file you need to run is called
Client.class.

If you are unfamiliar with running java files on your computer please see the following
website for help:
http://www.cs.colostate.edu/helpdocs/JavaInDOS.html


Note: Please make sure you have at least Java SE Development Kit (JDK) 6 update
10 release on your client machine before proceeding further. You will need this to
view the sample rich internet applications and read subsequent sections without
interruptions.

								
To top