UCCS CS5260 2012 SPRING
AJAX Chat Analysis and Design
Rui Zhao
Index
1 Preface ...... 1 2 Introduction ...... 2 2.1 Requirements ...... 2 2.1.1 Running Environments ...... 2 2.1.2 Developing Environments ...... 2 2.2 Features ...... 2 3 Architecture Analysis ...... 3 3.1 Architecture ...... 3 3.1.1 Definition ...... 3 3.1.2 Tables ...... 4 3.1.3 Client ...... 5 3.1.4 Server ...... 8 3.2 Techniques ...... 12 3.2.1 AJAX ...... 12 3.2.2 FLEX ...... 13 3.2.3 FABridge ...... 14 4 New Features ...... 15 5 Solutions ...... 16 5.1 Table Design ...... 17 5.1.1 User on-line Table ...... 17 5.1.2 Message Table ...... 18 5.1.3 Bans Table ...... 18 5.1.4 Invitations Table ...... 18 5.2 Client Design...... 19 5.3 Server Design ...... 19 6 Suggestions ...... 21 7 Reference ...... 22
AJAX Chat Analysis and Design
1 Preface
AJAX Chat is a free and fully customizable open source web chat software implemented in JavaScript, PHP and MySQL. Sound support is implemented using Flash, Socket support using Flash on client-side and Ruby on server-side. [1]
AJAX Chat integrates nicely with phpBB, MyBB, PunBB, SMF, vBulletin and other PHP community software. [1]
This paper starts with analyzing the chat system, and both server and client will be elaborated in four aspects (table design, infrastructure, collaboration and interface). The following chapters then discuss new features and how to add them to the system. At last, problems are proposed, especially those in design and codes, accompanied with suggestions about how to solve them.
1 AJAX Chat Analysis and Design
2 Introduction
2.1 Requirements
2.1.1 Running Environments
1. Server-Side [1] a) PHP >= 4 b) MySQL >= 4 c) Ruby >= 1.8 (optional) 2. Client-Side [1] a) Enabled JavaScript b) Enabled Cookies c) Flash Plugin >= 9 (optional)
2.1.2 Developing Environments
1. Zend Studio for Java and Php script development on both client and server; 2. FLEX for client flash development; 3. MySQL for server database development; 4. Ruby for server socket development. 2.2 Features Only main functions are listed in Table 2-1. Some of them are copied from AJAX Chat website. [1]
Table 2-1 Main Features
Main Feature Detail
Private messaging - Multiple/Private channels - Ignore/Ban and revoke users - List online/ignored/banned users - Change username - Private channels - Such as BB Code, hyperlinks, line Custom setting breaks. Possibility to delete messages inside the chat - Developed with Security as integral part - Blink window title on new messages - Show each user’s IP -
2 AJAX Chat Analysis and Design
3 Architecture Analysis
3.1 Architecture
System architecture will be analyzed in four parts: constant definitions, tables, client design and server design. Focus will be put on table design and infrastructures of client and server.
3.1.1 Definition
3.1.1.1 Role Definition
AJAX chat system defined five roles as default, as Table 3-1 shown.
Table 3-1 Role Definition
Role Definition
Chat Bot AJAX_CHAT_CHATBOT Administrator AJAX_CHAT_ADMIN Moderator AJAX_CHAT_MODERATOR User AJAX_CHAT_USER Guest AJAX_CHAT_GUEST
3.1.1.2 Channel Definition
Table 3-2 Default Channel Definition
Channel Definition Value
Public Channel channels[0] Public Private Channel channels[1] Private
3.1.1.3 User Definition
Each role can have several users. For users that were not defined as default user, their user id will be assigned with unused numbers in field ‘User ID’, as Table 3-3 shown.
Table 3-3 User Definition
User Name Password User Role User ID Channel
NULL NULL Guest - Public admin admin Administrator 1 Public & Private moderator moderator Moderator 2 Public & Private user user User 3 Public & Private apple apple Administrator 4 Public & Private pear pear User 5 Public & Private
3 AJAX Chat Analysis and Design
3.1.2 Tables
The chat system maintains four tables in database. Only ‘Field’ and ‘Type’ are copied from AJAX Chat website in each table. [2]
3.1.2.1 User on-line Table
Table 3-4 Table: ajax_chat_online
Field Type Notation
The table records every user chatting on line. A new value will be assigned to each guest. userID INT (11) For a registered user, userID will not be changed. userName VARCHAR (64) - userRole INT (1) Refer to Table3-1. channel INT (11) Channel Id on which the user is chatting. dateTime DATETIME Time of last access. ip VARBINARY(16) Remote IP of last access. Chat bot’s userID always is ‘2147483647’; and its username always is ‘ChatBot’.
Table 3-5 Example of ajax_chat_online
userID userName userRole channel dateTime ip
1 admin 3 500000001 2010-09-09 16:07:11 7f000001 3 user 1 500000001 2010-09-09 16:07:14 7f000001
3.1.2.2 Message Table
Table 3-6 Table: ajax_chat_messages
Field Type Notation
The table records all chat messages. Increased by 1 when a new message is id(PK) INT(11) inserted. userID INT(11) Refer to Table3-4. userName VARCHAR(64) - userRole INT(1) Refer to Table3-1. channel INT(11) Refer to Table3-4. dateTime DATETIME Time of message receipt. ip VARBINARY(16) Remote IP of message sender. text TEXT Message content.
4 AJAX Chat Analysis and Design
Table 3-7 Example of ajax_chat_messages
id(PK) userID userName userRole channel
1 2147483647 ChatBot 4 0 2 1 admin 3 500000001
dateTime ip text
2010-09-02 16:47:10 7f000001 … 2010-09-02 16:49:21 7f000001 …
3.1.2.3 Bans Table
Table 3-8 Table: ajax_chat_bans
Field Type Notation
The table records all banned users. userID INT(11) Refer to Table3-4. userName VARCHAR(64) Banned user name. User will be banned from now to dateTime. dateTime DATETIME Default dataTime is five minutes later from now. ip VARBINARY (16) Banned remote IP.
Table 3-9 Example of ajax_chat_bans
userID userName dateTime ip
6 apple 2010-09-09 16:20:03 7f000001
3.1.2.4 Invitations Table
Table 3-10 Table: ajax_chat_invitations
Field Type Notation
The table records all users and channels in invitations. userID INT(11) Refer to Table3-4. channel INT(11) Channel Id used in invited chat. dateTime DATETIME Time to join.
Table 3-11 Example of ajax_chat_invitations
userID channel dateTime
6 500000001 2010-09-09 16:20:03 3 500000001 2010-09-09 15:57:39
3.1.3 Client
5 AJAX Chat Analysis and Design
3.1.3.1 Infrastructure
Client infrastructure is described as Figure 3-1.
Comment B
Comment A FLEX Comment D FABridge
FABridge.js XML Stream AJAX Comment C
FABridge.as
Comment E
JSP HTML
Provide Style Config Setting
Invoke Action SWF Processor
User POST/GET Request Sender
Comment G Comment F
Comment A: AJAX receives XML stream.
Comment B: Update client view.
Comment C: Connection between FlEX and AJAX.
Comment D: Responsible for parsing XML stream and navigating JS instances.
Comment E: Responsible for updating SWF.
Comment F: Process actions performed on HTML.
Comment G: Send Http request to server.
Figure 3-1 Client Infrastructure
Client consists of two modules as Table 3-12 shown, with their descriptions.
6 AJAX Chat Analysis and Design
Table 3-12 Modules of Client
Module Detail
Translate XML stream to ordinary message and update flash on website: FABridge 1. JSP receives and parses XML message (AJAX); 2. JSP calls methods in ASP to updates flash on web page (FLEX). Responsible for performing user’s actions on web page: 1. Receive and parse input actions and parameters, such as JSP client setting, kicking some one and chat message; 2. Organize standard HTTP GET/POST messages; 3. Send messages to server.
3.1.3.2 Collaboration Diagram
When user inputs text and presses send button, or select/deselect a check box on client, a JSP method will be invoked. Different methods in JSP correspond to their own actions on web page. Steps in this process are shown in Figure 3-2.
HTML chat.js
User input
Invoke jsp method
Parse input
Organize message text
Send request(get/post)
Figure 3-2 Diagram of processing user input on client
When client received message from server, it then parses the message and refreshes client view with this new parsed message. Main steps in this process are shown in Figure 3-3.
7 AJAX Chat Analysis and Design
Bridge
FABridge.js FABridge.as FABridge.swf
XML Stream
Parse XML message
Parameters and values to update
Update client view
Figure 3-3 Diagram of processing server message on client
3.1.3.3 Data Interface
Table 3-13 Data Interfaces between Modules of Client
Module Module Data Interface
Array includes all [key-value] in XML Server FABridge form. Is the interface between FABridge.as and FABridge HTML FABridge.swf in FLEX. HTML JSP Embedded JSP methods in HTML. URL (“. /?ajax=true” or “./?ajax=true&lastID=XX&… ”); JSP Server “GET” or “POST”; NULL or Message.
3.1.4 Server
3.1.4.1 Infrastructure
Server infrastructure is described as Figure 3-4.
8 AJAX Chat Analysis and Design
Comment C Comment B
Application
Config
HTML Templates Comment A Use Socket XML Stream $_Request, $_Server Use server.rb Message Template Processor Management
socket config Use Comment D Use Write & Read server.conf Database Connector Database Comment G Php Platform
XML Message echo()
Comment F Comment E
Comment A: Comment E: From Flash XML Sockets. Functions: 1. Init database connection (parameters Comment B: are defined in server config); Functions: 2. Write chat information; 1. Define XML sream structure; 3. Query chat information used to update 2. Initialize and start socket; client view. 3. Listen socket in MPI; Class: 4. Parse XML stream. 1. lib\class\AJAXChatDataBase.php; Class: 2. lib\class\AJAXChatDataBaseMySQL.php. 1. socket\server.conf; 2. socket\server.rb. Comment F: Functions: Comment C: 1. Init request variaty; Server config. 2. Init session for each request; Class: 3. Parse info/command/message request; 1. lib\config.php. 4. Echo each request through XML stream(AJAX). Class: Comment D: 1. lib\class\AJAXChat.php; Functions: 2. lib\class\AJAXChatHTTPHeader.php; 1. Manage HTML templates; 3. lib\class\AJAXChatString.php. 2. Parse HTML contents. Class: Comment G: 1. lib\class\AJAXChatTemplate.php. Http socket.
Figure 3-4 Server Infrastructure
Server consists of three modules as Table 3-14 shown, with their descriptions.
9 AJAX Chat Analysis and Design
Table 3-14 Modules of Server
Module Detail
Listen HTTP requests and decode them to XML stream: 1. Server.conf defines parameters of socket, such as port and Socket IP; 2. Server.rb starts socket and port listener, receives and parses XML stream. Parse request and write useful data to database, then organize response to request. 1. Config.php defines template for request variables; Application 2. Templates are used to generate standard XML/XHTML stream when organizing response; 3. Database connector writes data to database and query data from database. Php Platform Send response.
3.1.4.2 Collaboration Diagram
When a request arrives, socket written in Ruby will be triggered to receive and parse it, then send results to php global variables, $_Server and $_Request. Application gets command/message from $_Request, processes command/message, and then generates response. By invoking method “echo” from php platform, application sends response at last. Steps in this process are shown in Figure 3-5 and 3-6.
server.rb AJAXChat.php config.php AJAXChatDataBase.php
XML Stream
$_Request, $_Server
Invoke( init config )
Invoke ( init database )
Start session
Pro A
XML Message Pro B
Figure 3-5 Diagram of processing client input on server
10 AJAX Chat Analysis and Design
Pro A:
if(already login) { if(a logout request) { logout() }
if(session ip != remote ip) { logout() } } else { Pro B: login() } if(is a ajax request) { if(already logged in) init view("chat" or null) { parse Info request, marked by "getInfos" if(view == "chat") { if(a delete command) if(channel != null) { { delete chat message in database if(user not online) } { logout() if(a chat message) } { parse message and write it to database if(is a ajax request) } { } init channel and update user status } send message (XML stream) to clients } } else } { send message (XHTML content) to set style cookie clients for non-ajax request set langCode cookie }
Figure 3-6 Diagrams of process A and B on server
If any event occurs (such as status change, message arrival) on server, it is necessary to notify all on-line clients about what happened. AJAX is used to decrease the information transported from server to client, in order to avoid refreshing web page for each event on server.
In addition, ‘ignore/accept’ a user is implemented in Pro A-‘init channel and update user status’.
In process B, method of sending XHTML message will be used when a user logs in or logs out, and when administrator kicks/bans some one from chatting room. Function of sending ordinary chat messages will use the method of sending XML stream.
3.1.4.3 Data Interface
11 AJAX Chat Analysis and Design
Table 3-15 Data Interfaces between Modules of Server
Module Module Data Interface
Standard HTTP request message, whose Client Socket content was in XML format. Global variables $_Request and Socket Application $_Server in Php Platform. A XML stream containing all [key-value] Application Php Platform to update. Standard HTTP message, whose content Php Platform Client is in XML format.
3.2 Techniques
3.2.1 AJAX
AJAX (Asynchronous JavaScript and XML) is a technique for creating fast and dynamic web pages. [3]
AJAX allows web pages to be updated asynchronously by exchanging small amounts of data with the server behind the scenes. This means that it is possible to update parts of a web page, without reloading the whole page. Classic web pages, (which do not use AJAX) must reload the entire page if the content should change. [3]
Browser Internet
An event occurs... Server 1. Create an XMLHttpRequest object; 2. Send HttpRequest.
Browser Internet 1. Process HTTP request; 2. Create a response and send data back to the browser.
1. Process the returned data using JavaScript; 2. Update page content.
Figure 3-7 Diagram of AJAX
AJAX is based on internet standards, and uses a combination of: [3] XMLHttpRequest object (to exchange data asynchronously with a server); JavaScript/DOM (to display/interact with the information);
12 AJAX Chat Analysis and Design
CSS (to style the data); XML (often used as the format for transferring data).
3.2.2 FLEX
Like Flash, Flex creates SWF files that are rendered by Flash Player. However, Flex is primarily a developer's tool and the way you develop Flex applications is entirely different than the way you develop Flash RIAs. All Flex development is based upon a framework that provides you with reusable and extendable UI components, data retrieval services, event handling functionality and much more. You can create RIAs in a familiar code-centric environment, but you still reap the benefits of Flash applications, which include: [4] The ability to design and implement human-centered user interfaces without worrying about browser limitations; A runtime environment with almost 100% deployment to all Internet users; The powerful ActionScript programming language; The ability to integrate rich media like streaming video and sound.
MXML
Compile SWF File
Action Script Upload
Download
Developer Web Server Customer
Figure 3-8 Structure of FLEX
In comparison, the Adobe Flash Authoring environment revolves around a timeline metaphor and visual development tools. Because of this emphasis, and despite the evolution of Flash's programming language, ActionScript, into a fully object-oriented ECMA-4-compliant language, Flash has traditionally been seen as a designer's tool for creating animations. Over the years,
13 AJAX Chat Analysis and Design many programmers have learned the benefits of using Flash to create powerful RIAs, but others have found the IDE to be difficult to understand. [4]
You should note that Flash and Flex can work together. As a matter of fact, Flex can work directly with other products in the Adobe Create Suite, as well. Designers and programmers can easily "create" in their own environments and then integrate their work to establish an entirely new breed of RIAs. [4]
3.2.3 FABridge
FABridge is a new JavaScript library enables developers to easily integrate Flex applications with Ajax or DHTML code running in the browser. [5]
The Flex Ajax Bridge (FABridge) is a small, unobtrusive library of code that developers can insert into a Flex application, a Flex component, or even an empty SWF file to expose it to scripting in the browser. [5]
FABridge is built with the “don’t repeat yourself” principle in mind. Rather than having to define new, simplified APIs to expose a graph of ActionScript objects to JavaScript, with FABridge you can make your ActionScript classes available to JavaScript without any additional coding. Once you’ve inserted the library, pretty much anything you can do using ActionScript, you can do using JavaScript. [5]
Flash Player has the ability natively, through the External API (the ExternalInterface class), to call JavaScript from ActionScript and vice versa. [5]
Developers may find the FABridge library useful if [5] They are using a rich Flex component in an Ajax application but don’t want to write a lot of Flex code. If they wrap the component in a bridge-enabled stub application, they can script it entirely from JavaScript – including using JavaScript generated remotely by the server; They have one or two people on their team who know Flex. The FABridge library allows everyone on a team to use the work produced by one or two Flex specialists; They are building an integrated RIA with both Flex and AJAX portions. While they could build the integration themselves using ExternalInterface, they might find it faster to start with FABridge as a head start.
14 AJAX Chat Analysis and Design
4 New Features
Following table shows the information to be captured and recorded.
Table 4-1 Information
Information Status Detail
Source IP address Available - Destination IP is actually the Destination IP address Not Available host/server IP. Source port number Not Available - Destination port number is actually Destination port number Not Available the host/server port number. Channel name is already supported, Chat channel information Partly Available while channel id is not supported. Application chat session could not provide efficiency evidence for each chat message, while http session Chat session information Not Available could. In additional, http session includes all information that application chat session contains. Chat messages Available - Timestamps Available -
15 AJAX Chat Analysis and Design
5 Solutions
By analyzing new features listed in Chapter 4, it is possible to categorize them as follows: Information that needs not to be transported from client: such transmission parameters that could be carried in TCP/UDP package between client and server. For example, each TCP/IP package header contains both source and destination IP addresses and ports. Therefore, it is not necessary to let client write these information in package message. Information that needs to be transported from client: comparing to that need not to be transported from client, it refers to the parameters or values customized by client. Such as message context and status of setting parameters.
Further discussion on following information is carried out as Table 5-1 shown.
Table 5-1 Information and Solutions
Index Information Discussion
NF 1 Source IP address - NF 2 Destination IP address No need to be captured from http session. NF 3 Source port number - NF 4 Destination port number No need to be captured from http session. Only when user logs in or changes channel, NF 5 Chat channel information channel information will be recorded. Be transported from client. Need to distinguish application chat session from http session. NF 6 Chat session information Application chat session is transported from client. Http session is obtained from server. NF 7 Chat messages - NF 8 Timestamps -
Therefore, we could capture the information as Table 5-2 shown:
Table 5-2 Information and Solutions
Index Information Solution Retrieve from
Source IP Be captured from http Php global variable NF 1 address session on server. $_Server['REMOTE_ADDR'] Be captured from http Php global variable Destination NF 2 session or from config file $_Server[‘SERVER_ADDR’] IP address on server. Source port Be captured from http Php global variable NF 3 number session on server. $_Server['REMOTE_PORT']
16 AJAX Chat Analysis and Design
Index Information Solution Retrieve from
Be captured from http Php global variable Destination NF 4 session or from config file $_Server['SERVER_PORT'] port number on server. Both channel name and id Channel name can be: private, are carried from client. public or username (for inviting Chat someone to join chat). NF 5 channel Channel name is in $_Request information [‘channelName’]; channel ID is 500,000,000 + userID. Application chat session: Application chat session: be carried from client. session name – “ajax_chat” Chat
NF 6 session Http session: be captured Http session: information on server. Php global variable $_Session[ … ] Chat - - NF 7 messages NF 8 Timestamps - -
Following steps show how to add new feature into current system.
5.1 Table Design Note: Red lines show the new created fields, while yellow lines show the changed fields.
5.1.1 User on-line Table
There is no need to record any session information, because the purpose of this table is to monitor current on-line users and their status temporarily.
Table 5-3 Table: ajax_chat_online
Field Type Notation
userID INT (11) - userName VARCHAR (64) - userRole INT (1) - channelId INT (11) Field ‘channel’ in Table 3-4. channelName VARCHAR (64) - dateTime DATETIME - source ip VARBINARY(16) Field ‘ip’ in Table 3-4. source port INT (11) Remote port of last access. destination ip VARBINARY(16) Local IP address of last access. destination port INT (11) Local port of last access.
17 AJAX Chat Analysis and Design
5.1.2 Message Table
It is necessary to record all channel information and session information, because of the purpose of this table.
Table 5-4 Table: ajax_chat_messages
Field Type Notation
id(PK) INT(11) - userID INT(11) - userName VARCHAR(64) - userRole INT(1) - channelId INT(11) Field ‘channel’ in Table 3-6. channelName VARCHAR (64) - dateTime DATETIME - source ip VARBINARY(16) Field ‘ip’ in Table 3-6. source port INT(11) Remote port of message sender destination ip VARBINARY(16) Local IP address of message receiver. destination port INT (11) Local port of message receiver. chat session VARCHAR (16) “ajax_chat” All session parameters could be recorded. http session … Could be divided to several fields to satify the requirements. * text TEXT - * Http session includes following information: ajaxChatUserID (1), ajaxChatUserName (admin), ajaxChatLoginUserName (admin), ajaxChatUserRole (3), ajaxChatLoggedIn (true), ajaxChatLoginTimeStamp (1284125987), ajaxChatIP (127.0.0.1), ajaxChatChannel (0), ajaxChatChannelEnterTimeStamp, ajaxChatStatusUpdateTimeStamp and ajaxChatInactiveCheckTimeStamp.
5.1.3 Bans Table
There is no modification to table: ajax_chat_bans.
5.1.4 Invitations Table
Table 5-5 Table: ajax_chat_invitations
Field Type Notation
userID INT(11) - channelId INT(11) Field ‘channel’ in Table 3-10. channelName VARCHAR (64) - dateTime DATETIME -
18 AJAX Chat Analysis and Design
5.2 Client Design For features in Table 4-1, there is no need to make any modification to client design, because all information could be obtained from server itself, and client has sent all required information to server.
If additional parameters have to be transported from client to server, and displayed on client, the design of client should be modified as Figure 5-1 shown. Modification locations are in red.
New functions should be added as following list: 1. Make new bridges in FABridge to receive, parse and display additional parameters; 2. Create new JSP functions to implement actions on additional parameters.
FLEX
FABridge
FABridge.js XML Stream AJAX
FABridge.as Comment A
JSP HTML
Provide Style Config Setting
Invoke Action SWF Processor
User POST/GET Request Sender
Comment B
Comment A: If new parameters have to be displayed in SWF, then it is neccessay to modify FABridge and SWF to support those parameters' display.
Comment B: Add new JSP methods to process new parameters.
Figure 5-1 Modifications to Client Design
5.3 Server Design Considering changes on tables and message processor, modifications must be made to those sub
19 AJAX Chat Analysis and Design modules which are in red in Figure 5-2.
New functions should be added as following list: 1. Table modifications; 2. Message Processor gets required information from $_Server and $_Session, when processing the message sent from socket; 3. Retrieve channel information from $_Request; 4. Database Connector organizes SQL query; 5. Database Connector executes SQL query to write data to database or read data from database.
Methods and variables which will be used in codes are shown as following list: 1. $_Server and $_Session: could be called anywhere in AJAXChat.php. $_Session (http session) could be called only after invoking session_start method. 2. Application chat session: always is “ajax_chat”. 3. Chat channel: channel name can be get from $_Request [‘channelName’] in initRequestVars() function in AJAXChat.php, while channel id is 500,000,000 + userID.
Application
Comment A Config HTML Templates
Use Socket XML Stream $_Request, $_Server Use Message Template server.rb Comment B Processor Management
socket config Use Comment C Write & Read server.conf Use Database Connector Database
Php Platform
XML Message echo() $_Server $_Session
Comment A: Get IP addresses and port numbers from $_Server; Get http session information from $_Session; Get chat session information; Get channel name from $_Request ['channelName'].
Comment B: Modify methods to organize a new SQL query.
Comment C: Modify tables in database.
Figure 5-2 Modifications to Server Design
20 AJAX Chat Analysis and Design
6 Suggestions
While reading codes of AJAX Chat software, I found following problems: 1. Some files’ length is more than 3000 lines, and it will surely decrease the readability and destroy the structure of codes; 2. Inadequate code comments, the best ratio of comments to codes is between 1:1 and 2:1; 3. In php coding, it is better to use $_Get and $_Post instead of $_Request. In ordinary, $_Request could stands for $_Get. And when $_Get is null, $_Request will refer to $_Post. However, when both $_Get and $_Post exist, who does $_Request refer to? And how to get $_Post by using $_Request now? Therefore, $_Request is a dangerous variable and is not recommended in php coding; 4. New features suggested: a) Banned time. The system bans a user only for five minutes, and it is not possible to choose a start time and end time for banning; b) No registration entry. The system does not provide an entry to create new users, and there is no table for saving user information. Of course if the chat system is combined with a forum, this will not be the problem. If registration is not allowed for some reasons, the table for user management is still in need. c) Fusion between authority management and role management. The system does not connect each role with an authority by an interface, but by simply putting authority management into role management; d) Whether actions of log in or log out should be recorded into user on-line table or another new table permanently will be further discussed. Since our purpose is to make the chat system a forensic one, maybe any action on-line should be recorded without any exception; e) It is better to retrieve environment information of OS from each client, and we could consider it an evidence of chatting actions. Because probably it is impossible to know who is actually using a specific user name. One of the important information is user name logged on OS.
21 AJAX Chat Analysis and Design
7 Reference
[1] https://blueimp.net/ajax/ [2] http://sourceforge.net/apps/mediawiki/ajax-chat/index.php?title=Main_Page [3] http://www.w3schools.com/Ajax/ajax_intro.asp [4] http://learn.adobe.com/wiki/display/Flex/Get+oriented+to+Flex [5] http://tv.sys-con.com/node/193201
8 Notation
Rui Zhao all rights reserved!
22