Optimized chat server protocol for server side scripting languages

Optimized Chat Server Protocol for Server Side Scripting Languages

A. P. D. Krishnajith, R. D. I. P. Devinda and R. G. Ragel Department of Computer Engineering - University of Peradeniya - Sri Lanka

[email protected], [email protected] and [email protected]

Abstract— Nowadays using comprehensive web chatting is a very popular feature in websites. Most of the websites use server-side scripting languages to deliver dynamic web pages to their users. The problem of implementing a chat server with these languages is that there are no long running processes to establish a firm long lived socket connection with the server. Therefore, when the server needs to send some information immediately to the web client, there should be a mechanism to do so. In this paper, we discuss our protocols and optimizing techniques for such kind of server-client environment. The target of this project is to use our protocol to design and implement an optimized web chat client and a server using a server side scripting language.

Keywords: Chat Server; Web; Protocol; Scripting Languages

I. INTRODUCTION Most of the community based web components are

interested in introducing a web chat component to their websites as it improves the productivity of their web sites. Cafolla and Knee [5] show the importance of group and individual chat in distance learning through the web. Many other researchers [11] [12] [13] [14] including O’Neill and Martin [10] have also shown the importance of text chat in web applications and how it can be used in a workplace. Even though the importance is understood, most of the websites are facing the problem of running a dedicated ‘chat server’ on their server since they are hosted in a shared web hosting environment and uses server-side scripting languages. Therefore, it will be beneficial if we can introduce a comprehensive open source web chat system that can be easily integrated to any existing web page where the server is written in a server-side scripting language. This will enable website owners to host their ‘chat servers’ at the same place (instead of a separate server) where they host their websites.

PHP, JSP and ASP.net are popular server side scripting languages that deliver dynamic web pages to users. However, the main challenge in implementing a chat system with these languages is that, they only process the pages when a request reaches the server, and then deliver the page. That is, there are no ‘long running’ processes to establish a firm long lived socket connection with the server. Also we are dealing with a web client in which a request to the server returns the response, only when the connection is closed by the server. Therefore, when the server needs to send some information immediately to the web client, the server does not have a connection with the client. This is the main problem that we have solved in our work. Please note that we used JavaScript for our client and AJAX [20] to communicate with the server instead of using applets or flash modules. This decision is

made to eliminate the burden of users installing browser plug-ins to use our chat application, since we target large audience of users who may not visit the system very frequently. JavaScript and AJAX are supported by most of the modern browsers.

The next major problem that we addressed is keeping a reliable list of online users and notifying the clients about the changes of online user list, to ensure that they also have a shadow copy of the online user list. On the other hand, when sending messages to the server from the client (frequently the chat messages) we ensured that the other client receives the messages in the same order, since this is very important when sequential data is sent through several connections.

In addition, keeping the delay between chat sessions at a reasonable interval is important, as it will avoid overloading the server. So, we optimized the protocol and server side code as well as web client to achieve acceptable performance limit.

While developing the clients, we always considered about the convenience of integrating our chat client to an existing web page. Finally we could achieve easy integration where just adding two lines of code to an existing web page would add the chat client to the web page. The chat client can withstand even a slow, unreliable internet connection. Also, users can add more clients to a chat group while they chat with others. It introduces a convenient way of having group chats.

II. RELATED WORK There is an open-source chat server and web client called

PHPOpenChat [1] which is written in PHP and JavaScript. It is a group chat box. Each and every user logged in to the server sees what everyone else is typing. There is no support for one to one chatting. Also it is difficult to integrate this system with a web page. To use this, the chat users need to go to a different page instead of chatting while browsing the pages in the web site. The client is not intelligent and therefore may overload the server. Our protocol solves all the above mentioned problems. Also, when comparing this system against our system, our implementation performed better and with lesser server load. For example, PHPOpenChat makes minimum 25 requests to the server in a minute even when the client is not actively chatting, but our system makes only 4 requests if the client is not actively chatting. This reduces the server load and increases the performance of the system.

Welie and Eliëns [3] have proposed a web chat architecture, where the server delivers applets to the browser, and the applets communicate with each other to establish a

chat system. This approach does not meet our requirements for several reasons. One is every user has to install add-ons to run the applet in the browser. Also, both users need to have public IPs to reach the other client. In addition, most browsers today do not allow applets to communicate with a domain other than the domain where it was downloaded from, for security reasons. When compared against our system, this system cannot be integrated easily while keeping wide support for browsers and cannot communicate with users who do not have public IPs; this architecture is not suitable for our solution. Our protocol overcomes all the mentioned drawbacks of this protocol.

Oikarinen and Reed (RFC1459) [4] introduce a standard protocol for internet chatting. They introduce a mechanism called channels to the chat, where each member of a particular chat belongs to a channel. Messages sent to a chat channel will be sent to all the members of the channel. A user can be in any number of chat channels, and a channel can have any number of members. This concept is used in our chat protocol, to easily implement group chats, where we have chat channels as chat groups. This protocol assumes that server to client or client to server communication can occur at any time, since the client is always connected to the server. In our case, we do not have connection where server initializes a message and can send a message to a client as in a normal socket connection. To overcome this, we developed our own protocols to perform chat in an environment like this. Comparing against our protocol, this protocol cannot be easily implemented in the previously mentioned ‘browser and web-server’ environment. We also propose solutions for overheads of the protocol in a web environment.

RFC1459 [4] also introduced a messaging mechanism to communicate between a server and a client, in which all the events are sent by a message. We altered this message mechanism to suit our needs.

Dewes et al. [9] have done an analysis of existing chat systems. They wrote “unfortunately there is no common protocol base for chat systems. Rather there are a multitude of protocol variants whose specifications, with some exceptions, such as IRC and ICQ, are unavailable or ill defined”. Therefore, there is very limited literal evidence of researches in the field of web chatting and even chat protocols. Further, they say that “web-chat systems, each based on different protocols using a wide range of port numbers. These systems and protocols do not only vary widely but are usually not well documented”. Also, they have identified that the IRC [4] chat is more complex to use in a web chat and should be simplified to use in web chat. We have successfully simplified most of the concepts of IRC in the propose protocol.

The main problem in existing chat systems is that they expect consistent server to client communication where the server can communicate with the client at anytime. But this is not possible with web chats since the server cannot send some data to a client, until the client reach the server. So, we implement a polling mechanism where client reaches the server periodically, which is discussed in details later. In addition, most of the existing chat protocols do not address situation such as message disordering, vanishing messages, etc. since they expect a single continuous connection from client to the server, where those are not much of problems. We define protocols to overcome these problems, since in a web chat a new connection is used each time a client needs to send data to the server and it is vital to address all these issues.

III. BACKGROUND After surveying a number of available popular chat

programs (such as Skype [6], Google Talk [7]) and studying some previous research [16] [17] [18] [19], we identified the following key features of chat systems. They are implemented as basic functions of our web chat application considering the range of targeted users of our system. Authentication to the server, proving the identity, is usually performed by providing a username and a password. It is important that the system has the ability to handle a buddy list (a list of special users with whom that particular user is allowed to chat) and showing a list of online buddies. The system should not show an offline buddy as online. To achieve this, the chat system should be able to detect an offline user in two cases: (1) when intentionally signing out from the server or closing the browser or (2) unintentionally disconnecting from the server. The chat system should allow users to start a chat from any side and to allow one to one chatting. Consistency and ability of reliable message passing are key considerations and the messages should not be lost or disordered. Apart from one to one chatting, group chatting is also enabled. One to one chat is also a group chat with two members.

To avoid servers getting jammed because of the automatic requests of the chat system, we should be able reduce the traffic to the server and should optimize the server processing time. Even if the server is used effectively, the speed of the message delivery should be reasonably quick and should work in slow internet connections. Importantly, the server should be able withstand in a long-run (no garbage should be kept in server databases).

Apart from the basic features described here, we kept our eyes open on few other features such that they will make our system more usable. The look and feel of the user interface should be easily altered according to the theme of the web site and it should be attractive, clean and user friendly. In addition,

to implement the web chat client, we followed JavaScript object oriented programming concepts [2] to allow programmers to easily alter the system.

IV. PROTOCOLS AND SYSTEM DESIGN A. Communication protocol in the chat system

Figure 1 gives an idea about the basic communication mechanism used in the system. When a server needs to send some messages to a client, it queues the messages in a database, until the client retrieve the messages from the server. These queued messages are called Notifications and there are many types of Notifications such as online user notifications, offline user notifications, chat messages received notifications, etc. These notification types can be extended to send different notifications to the client since it uses a flexible object, encoded in JSON [8] string to send messages. The available notifications are sent to a client as the response to the presence notification that is a request sent periodically by a client. This will be described later in detail. Each notification has a time stamp attached to it to avoid disordering of notifications. This is important for ‘chat message received’ notifications. Notifications do the necessary communication to run the chat. Other than polling the server periodically, when a client sends a chat message to a chat group, a separate request is used to transfer the message to the server.

Figure 1: Basic communication mechanism used in the system

B. Server – Client Communication Two mechanisms of achieving effective communication

between the server and clients are proposed. Both of these mechanisms are compared and evaluated for choosing the more appropriate one. The polling mechanism is the best solution for reasons discussed later.

C. Protocol to send information from server to client Figure 2 shows the first protocol proposed for sending

information to the client. The active connection checks whether any notifications are available by checking the database. If not it sleeps for few hundreds of milliseconds (for example 500ms) and checks again. This repeats until there are any notifications or until predefined time period has expired. When notifications are discovered by the active connection, the connection responds with those notifications and

disconnects. In order to avoid network timeouts, the connection disconnects after predefined time period of being active. The steps given in Figure 2 repeat until the client disconnects from the server.

Figure 3 depicts the second protocol proposed for sending information to the client. There, a single connection is made to the server and even if there are no notifications it responds without waiting. The steps given in Figure 3 repeat until the client disconnects from the server.

Figure 2: Proposed protocol I for server to client communication

We implemented both protocols for testing and

evaluation purposes, from which we learnt the advantages and disadvantages. The first implementation takes a notification very quickly to the client (average delay is far less than 1s). But it has few drawbacks. The first one is that the number of active connections and the queue for incoming connections has a limit in a web server. So, when there are a lot of online clients, connections tend to be refused. Then some clients may not be able to connect and the server gets jammed with the traffic.

The second protocol introduces at least a delay of 1s for sending a notification to the client. As we experienced even in a dial-up connection hardly exceeds delay of 2s to go to the server and comeback. For chatting purpose, a delay of 2s is barely noticeable. Most of the time, the network delay is less than 1s. Therefore, by considering the above facts we have decided to go with the second protocol since the first method introduces extra overheads when number of online clients is large.

D. Communication from client to server When a client needs to send a message to a specific chat

group, it sends a request to the server with the message and the group id. These requests are separate from the presence notifications. In response to the request, ‘message successfully received’ will be sent back by the server if it is received correctly. A special mechanism is used to keep the order of the messages and to avoid vanishing messages when a request sent to the server fails. This mechanism is discussed in detail later.

Figure 3: Proposed protocol II for server to client communication

E. Tracking and notifying online users A consistent online users list is a major feature that the

users of a chat client should have according to Tran et al. [17]. Normally chat systems detect offline users when the socket connection between the server and the user are closed, and detects online users when a connection is made. Since, we do not have a socket connection with the server, to track whether a user is online or offline, a mechanism called ‘presence notification’ is used. Presence notifications are sent periodically by the clients, with a 1s to 15s period in between, to inform that they are still online and to get the notifications available in the server. Figure 4 shows the flow of the presence notifications. Step (F) is an optimization step and will be described later.

‘last reached’ time-stamp in Figure 4 indicates the last time that a client sent a presence notification and ‘online flag’ shows the status of a user whether the system identified the user as online or offline. ‘online flag’ allows detecting online users easily and also allow easy detection of transitions of online to offline and offline to online, which is where we need to send notifications to other clients. Step (D) and (E) shows how a client becomes ‘online’. In addition, in step (E) and (I), sending the notifications means adding the notifications to notification queue of the server (adding messages to the notifications table of the database).

Marking users as offline, who has ‘last reached’ time-stamps older than 20s is another problem, since the server does not have a long running process to check and mark offline users periodically. We assume that the administrator of

the chat does not have permissions to schedule a recurrent event on the server to do this, such as a cronjob that runs a script. So we use one of the presence notifications to do marking offline users. Choosing the notification is explained in the optimization section. Steps (G), (H), (I), (J) and (K) in Figure 4 shows the process of checking and marking clients as offline. Marking users offline is performed by looping through the users’ ‘last reached’ time stamps and identifying those who exceeds the set limit.

Figure 4: Flow of the presence notification

If such a client has online flag indicating that the user is

online, the user will be marked offline and notifications are sent to all online buddies of the user asking to make the user offline.

Since we mark users offline when they have ‘last reached’ time-stamps older than 20s, considerable network delay of slow internet connections will also impact this decision. The system should take this into account to prevent the user appearing offline because of the network delay added to the polling interval between two presence notifications. Therefore, a margin of 5s added between the maximum polling interval and the time period used to mark a user offline, to allow network delays. In addition, when a presence notification sent to the server fails, a new request is sent after 500ms. The 500ms delay has been introduced to avoid crashing the browser when all requests sent to the server are failing.

All the concurrent requests are handled by the Web Server where the system is hosted and concurrent requests for data in the database are handled by the database system we used, MySQL.

F. Protocol to avoid message disordering and vanishing

In a chat, messages should not be sent out of order. In our protocol each message typed by a user is sent in a separate request to the server to avoid delays. Therefore, there is no guarantee that the messages sent by the client reaches the server in the correct order. A time stamp or sequence number attached with each message cannot be used here since the server needs to queue the message to send to clients just after receiving it. It would be inefficient for the server to wait until missing messages in the sequence reach the server (this increases the server load). Alternatively we use a protocol in which the client must make sure that the messages typed by the user are sent and the server receives them without any disordering. Since the order of sent messages is only important within a chat group, the following mechanism is applied for each chat box. A chat between two or more people, who are in the same chat group, is shown in a single window in the chat and is called a chat box. So, following mechanism is used to avoid disordering, vanishing and to send the massage as quickly as possible while keeping the server load at a minimum level. 1. When a user type and send a message, if there is no

connection made with the server for sending massages, send a new request to the server with the message. Set a flag in the client stating that there is an active massage-sending connection. Store the messages sent with the request temporally to use if the connection failed.

2. When a user type and send a message, if there is a request that is still not served, queue the message in the chat box.

3. When the connection responds do step 4. 4. Check whether there are any queued messages and if

there are any, send the messages to the server in one new request, keeping the order and set the flag stating that there is an active massage-sending connection. Store the messages sent with the request temporally to use if the connection failed.

5. If the connection failed append the messages that were sent with the previous connection to the beginning of the queue and do the step 4.

6. When a user sends a message from the chat box do steps 1 or 2 accordingly.

7. This mechanism is done in each chat box since the order is only important within a chat box.

G. Taking network delay into account

Since we have a polling mechanism to get notifications from the server, we need to take the network delay into account. The clients keep on poll the server to know whether the server has any notifications. A minimum polling period (1s) is introduced when the client is chatting actively. This 1s delay is introduced between a successful response and the next request. But say the network delay to send a request to the server and to get notifications as response is 0.75s. Then the total delay is 1.75s even though we need 1s polling period. So, it is always worth to know the average network delay to adjust the poling period. Therefore we can adjust the polling interval by reducing the network delay for the regular polling interval. In the above case only 0.25s delay will be applied between successful responses and next requests.

We calculate the network delay by counting the time between each successful request and successful response. Then we take last 5 network delays and take the average. This allows us to track the changes in network delay. Since the connection may speedup or slowdown from time to time, we need to capture this behaviour. After calculating the average network delay, we subtract it from the delay period, and call it as effective delay. Minimum effective delay is always kept greater than 100ms to avoid the browser crashing since sometime network delay may suddenly go down to somewhere around 20ms and introduce a heavy loop in the client.

H. User interface design

Considerable number of researches has been done on user interface design in a chat system. Vronay et al. [16] shows how the standard chat user interface can be improved effectively and we used some of the valuable finding such as showing timestamps in chats, separate chat boxes, removing smooth scrolling, etc. from these findings. Further, since expressing emotions are important in text chatting, as identified by Bodine and Pignol [15], support for smilies (eg. :-), :-( ) is implemented. Text faces are automatically converted in to faces. Furthermore, Tran et al. [17] discussed about three types of awareness that a chat system should provide to its clients. Those are awareness of multiple concurrent conversations, presence awareness of a group conversation, and visibility of moment to moment listeners and viewers. We have implemented all these three in our chat system by introducing chat boxes, special notifications for group chats (users joining and leaving) and by showing list of users who are currently in a chat group.

V. OPTIMIZATION It is important to make sure the server does not get

jammed by running the chat server since it can be a shared server for hosting multiple web sites. So we optimized our

chat to use minimum server resources, while more load is distributed among clients.

A. Database optimization and usage of stored procedures We can reduce the time that we are spending on heavy

database manipulation tasks by using stored procedures at the database level. For an example when retrieving online users first retrieve the users’ online buddy list and then send notification for each online buddy by a PHP program that quarries the database several times to do this. We can reduce time spend on this task by using stored procedures in the database. By performing experiments we got to know that for the same tasks, stored procedures saves 90% of time compared to the time taken by the same task written in PHP without stored procedures.

We have used indices effectively for the tables which are frequently searched. The messages table stores all the messages needs to be sent to a client, until the client reaches the server. Therefore, we have added index for client id since the table is frequently searched by client id. This reasonably optimizes message passing even if all the messages are stored in a single table.

B. Polling interval reduction

When a client is idle without chatting, the polling interval to the server can be increased. When a client is actively chatting, the interval is 1s and when he starts to become idle, the polling frequency is reduced step by step and polling interval reaches a maximum of 15s ultimately. This reduction saves a lot of server processing time, even if a client may have to wait at most 15s to chat with an idle client. This is not much noticeable. These delays and other delays in the system are chosen according to the research done by Gandhi [18] and by experiments done by us. C. Last run time-stamps

The server uses presence notification, periodically coming from clients to mark the offline users since the server can’t run its own long running processes to mark offline users, as discussed in section 3. Also presence request is used to collect garbage from the database such as groups with no online users and notifications that have been sent to offline users. So it would cause heavy processing if we run these two procedures during each and every presence notification. So we store a timestamp in the database stating the last time these procedures have been executed called ‘last time run’ timestamp. Each presence notification checks the timestamp and a procedure runs only if it is older than 15s. Then it updates the last run timestamp. Step (F) and (M) of the Figure 4 show these steps.

VI. CONCLUSION AND FURTHER WORK We designed and implemented a chat system with the

protocol proposed and tested successfully. The chat is running smoothly without overloading the server, without crashing clients, without missing or disordering chat messages, keeping

up-to-date online user list in each client and without introducing reasonable delay to active chats.

According to Vronay et al. [16], a chat system can be improved by showing exact status other than just online or offline (such as whether other user is typing or not) which is not implemented in our chat. With the current notification system that we have, we can add such features easily without much overhead. Also we can create a desktop chat client with this chat server very easily.

In conclusion, we have proposed and successfully evaluated two protocols for a chat server in a server side scripting language and we have identified the one that is more suitable.

ACKNOWLEDGEMENT We would like to thank D. Elkaduwe of Computer

Engineering, University of Peradeniya for his valuable and continuous feedback on this project.

REFERENCES [1] PHPOpenChat (POP), Available at http://www.phpopenchat.org/,

Accessed on 2009 Aug. [2] Object Oriented Programming in JavaScript -

http://mckoss.com/jscript/object.htm, August 2009 [3] Martijn van Welie and Anton Eliëns, Chatting on the Web, Vrije

Universiteit, Department of Mathematics and Computer Science [4] J. Oikarinen and D. Reed, RFC1459 - Internet Relay Chat Protocol, May

1993, Network Working Group [5] Ralph Cafolla and Richard Knee, Adding Interactivity to Web Based

Distance Learning, Department of Educational Technology and Research, Florida Atlantic University

[6] Skype, http://www.skype.com/ 2010 Jan [7] Google Talk, http://www.google.com/talk/, 2010 Feb [8] Introducing JSON, http://www.json.org/, 2010 Feb [9] Christian Dewes, Arne Wichmann, Anja Feldmann, An analysis of

Internet chat systems, 2003 Aug, IMC’03, Miami Beach, Florida, USA [10] Jacki O’Neill, David Martin, Text Chat In Action, GROUP’03, 2003

Nov, Sanibel Island, Florida, USA. [11] Isaacs, E. et al I M everywhere: The character, functions, and styles of

instant messaging in the workplacem, 2002, CHI’02. [12] Nardi, B., Whittaker, S., Bradner, E., Interaction and outeraction: instant

messaging in action, 2000, CSCW’02. 79-88 [13] Bradner, E, Kellogg, WA & Erickson, T. The adoption and use of

Babble : A field study of chat in the workplace, 1999, ECSCW 1999 139-158

[14] Churchill, E. & Bly, S. It’s all in the words: supporting work activities with lightweight tools, 1999, GROUP 99. 40-49

[15] Kerry Bodine & Mathilde Pignol, Kinetic Typography-Based Instant Messaging, 2003 Apr, Carnegie Mellon University,

[16] David Vronay, Marc Smith, and Steven Drucker Alternative Interfaces for Chat, 1999, Virtual Worlds Group, Microsoft Research, UIST ’99.

[17] Minh Hong Tran, Yun Yang, Gitesh K. Raikundalia, Supporting Awareness in Instant Messaging: An Empirical Study and Mechanism Design, 2005 Nov, Swinburne University of Technology and Victoria University, Proceedings of OZCHI 2005, Canberra, Australia.

[18] Shruti L. Gandhi , Vishal K. Singh and Henning Schulzrinne, Analyzing User Behavior in Instant Messaging

[19] Watching Together: Integrating Text Chat with Video, Justin D. Weisz, Sara Kiesler, Hui Zhang, Yuqing Ren, Robert E. Kraut, Joseph A. Konstan, 2007 May CHI 2007, San Jose, California, USA.

[20] AJAX (Programming) - Wikipedia http://en.wikipedia.org/wiki/Ajax_programming, Mar 2010