Patent Application
20090063638
The present invention generally relates to messaging systems and, more particularly, to techniques for processing messages in such messaging systems.
Instant Messaging (IM) is an extremely popular software application. In general, IM offers a form of real-time communication between two or more people based primarily on typed text. The text is conveyed via computers (forming a messaging system) connected over a network such as the Internet. Some popular IM services include AIM™ (America Online LLC of Dulles, Va.), MSN Live Messenger™ (Microsoft Corporation of Redmond, Wash.), Yahoo Messenger™ (Yahoo! Inc. of Sunnyvale, Calif.) and Gtalk™ (Google Inc. of Mountain View, Calif.).
It is estimated that there are tens of millions of instant messaging users all over the world. Private users typically use instant messaging to keep in touch with friends and families, while corporate users typically exchange instant messages to discuss work. Compared to other methods of communication, instant messaging offers several advantages. Its almost synchronous nature makes it ideal for simple requests and responses. Instant messaging also typically provides presence and event notification which makes it easy to keep track of the availability of colleagues and friends (“buddies” in IM terminology). In addition, most instant messaging systems today incorporate support for voice or video chats as well as file transfer, making it an integrated environment for a wide variety of communication needs.
Almost all major instant messaging systems route messages through centralized servers. However, due to the large volume of instant messages, these servers can act as significant system bottlenecks, especially during severe overload conditions. Current messaging systems do not adequately optimize message processing during such overload conditions.
Principles of the invention provide techniques for processing messages in a messaging system, particularly during an overload condition. The messaging system may preferably be a real-time or instant messaging system.
For example, in one aspect of the invention, a method of processing messages of an instant messaging system includes the following steps. A message from a first instant messaging user is received during an overload condition. A message type associated with the received message is determined. The method then decides whether to send the message to a second instant messaging user based on the determined message type of the received message.
The message is preferably not sent to the second instant messaging user when the message type is a presence message type or a hint message type. The message is preferably sent to the second instant messaging user when the message type is a text message (e.g., chat message) type.
The message type determining step may further include parsing a header of the received message to determine the message type. The deciding step may further include applying a processing policy based on the message type of the received message. The receiving, determining and deciding steps may be performed in a server of the instant messaging system or a proxy of the instant messaging system. A communication protocol used by the instant messaging system may include a Session Initiation Protocol (SIP). An article of manufacture may include a processor-readable storage medium storing one or more software programs which when executed by a processor perform the receiving, determining and deciding steps.
In another aspect of the invention, a method of processing messages in an instant messaging system includes the following steps. Presence information associated with a first instant messaging system user is received. The presence information is sent to a second instant messaging system user when the second messaging system user requests the presence information associated with the first instant messaging system user.
The second instant messaging system user may request the presence information associated with a first instant messaging system user by selecting the first instant messaging system user on a display of the second instant messaging system user. The presence information may be sent when the second instant messaging system user clicks on a corresponding icon of the first instant messaging system user. The presence information may be sent when a representation of the first instant messaging system user is displayed in an instant messaging window of the second instant messaging system user. The representation of the first instant messaging system user may be one of an icon and a name of the first instant messaging system user. The presence information may be sent based on at least one of a temporal proximity (e.g., recent) and a frequency of communications (e.g., frequent) between the first instant messaging user and the second instant messaging user. The presence information may be sent, when a chat window is attempted by the second instant messaging system user to the first instant messaging system user. The receiving and sending steps may be performed in one of a server of the instant messaging system and a proxy of the instant messaging system. An article of manufacture may include a processor-readable storage medium storing one or more software programs which when executed by a processor perform the receiving and sending steps.
In yet another aspect of the invention, a method of processing messages of a messaging system during an overload condition includes receiving messages from messaging system users, sending one or more of the received messages that are of a substantive communication type, and discarding one or more of the received messages that are of a nonessential message type. The method may also assign a discard probability to a message based on the type of the message.
Apparatus for processing messages of a messaging system during an overload condition may includes a memory, and a processor coupled to the memory and operative to perform the receiving, sending and discarding steps.
These and other objects, features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
While illustrative embodiments of the invention will be described herein in the context of instant messaging applications, it is to be understood that principles of the invention are more generally applicable to any type of messaging system.
Various IM-related phrases and terms will be used herein. However, it is to be understood that principles of the invention are not intended to be limited to the illustrative definitions given below. For example, as used herein, the phrase “chat messages” refers to text messages sent and received by users wherein the users are substantively communicating (“chatting”) with one another. “Hint messages” are messages generated by the IM client software when a user is typing or editing a message. A user may, for example, hold off her own typing when she receives a hint message that indicates that her buddy is currently responding. A “buddy” is a frequent contact with whom a user chats with online. A “buddy list” is a contact list that enables the user to know when their contacts are online and can communicate. “Presence messages” are messages used to notify the status of buddies in a user's buddy list. A user can see who is online, who is offline, who is away (still online but not available to chat), etc. “Icon and binary messages” are messages used to upload a user defined picture to the instant messaging server, to download the picture of buddies from the instant messaging server, or to deliver voice/video chat and file transfer packets when the two users cannot communicate directly. Typically, file transfer, voice/video chats, etc., are conducted between the two users directly without going through the server. However, if both users are behind firewalls, then the communication has to be relayed by the server. “Service control messages” are messages for controlling log in and log out, server redirection, application level keep alive, etc.
While this architecture facilitates firewall traversal and gives instant messaging service providers more control over its subscribers (users 12), it creates a potential bottleneck at the servers. This is especially so for large instant messaging operators with tens of millions of users and during flash crowd events (i.e., events that cause a sudden spike in the volume of IM traffic and, thus, an overload condition).
Principles of the invention address the problem by providing techniques for optimizing message processing during overload conditions. In one embodiment, this is accomplished by determining which messages to discard and how to process presence information when instant messaging servers are overloaded.
One solution to protect instant messaging servers from being overloaded may include dropping messages based on customer types or revenue expectation. For example, a service provider could offer several levels of service to its customers. During overload, it can prioritize messages from premium customers (who pay more) while dropping messages from ordinary customers (who may sign up for free).
The main drawback of such a solution is that it does not take advantage of the specific characteristics of instant messaging traffic, i.e., not all instant messages are equally important.
We have realized that a large percentage of (if not most) instant messaging traffic is due to “nonessential traffic” (or nonessential messages). By way of example, as used in the illustrative embodiments herein, “nonessential traffic” may include traffic other than chat messages, e.g., nonessential messages may include, but not be limited to, presence messages and hint messages. Thus, principles of the invention utilize this realization and provide for an instant messaging server to protect the instantaneous nature of the communication passing through it by dropping some or all nonessential traffic during overload. Such a methodology may result in significant load reduction for instant messaging servers. This solution may be complementary to solutions that drop messages based on customer types or revenue expectations. The inventive solution has the advantage of being minimally intrusive because the nonessential traffic it drops is unlikely to cause major inconvenience to instant messaging users.
We also realized that the fact that presence information represents a significant portion of instant messaging traffic is partly due to the broadcast nature of the presence traffic. That is, when the presence status of an instant messaging user changes, such information will be propagated to all of her buddies (users on her buddy list), thus potentially creating a flood of messages. Another aspect of the invention is to process presence information in an on-demand fashion (i.e., when it is really needed), as will be explained in detail below.
Principles of the invention are based on the insights we gained from a measurement study we conducted of instant messaging traffic in a major enterprise network. We found that a large percentage of instant messaging traffic is due to nonessential traffic, while chat messages (i.e., substantive communication messages) constitute only a small percentage of the total instant messaging traffic. Therefore, according to principles of the invention, IM servers (e.g., chat servers and BOS servers in
For example, if a hint message is dropped, then a user may not be notified that her buddy is in the process of replying to her. This fact, however, will become apparent when she eventually receives the text message (chat message) from her buddy. For most users, the delivery of hint messages is less important than the delivery of the actual text messages. As another example, if presence messages are periodically refreshed, then a user may have an out-of-date view of the availability of her buddy when a presence message is dropped, e.g., she may think her buddy is online while her buddy has gone offline. This information, however, can be refreshed during the next interval or when she actually sends a message to her buddy. Hence, dropping some presence messages periodically, while causing minor annoyance, is more acceptable than dropping text messages.
Thus, method 20 can be implemented in one or more (preferably all) of the servers in the messaging system (e.g., chat servers and BOS servers in
It is understood that the above embodiment is just one of the many possible implementations of principles of the invention. Thus, other embodiments that drop nonessential messages without delivering them to the end users may be implemented. Also, such processing may include selective discard of icon messages used to display instant messaging users' images.
More generally,
In addition, as part of the selected policy, the messaging system may assign a discard probability to messages based on their types. For example, presence messages may have 30% probability of being discarded, icon messages may have 50% probability of being discarded, while text messages may have 0% probability of being discarded.
As previously mentioned, we realized that presence related traffic contributes to a substantial fraction of the overall instant messaging traffic. In current instant messaging systems, the presence update is automatically propagated to all related instant messaging users. For example, if an instant messaging user is included in the buddy list of 100 other users, then whenever this user changes her status (e.g., going online, offline, away, do not disturb, etc.), her status will be propagated by the instant messaging server to the 100 users. While this allows those users to have a quick view on her presence, it creates a potentially large amount of traffic on the instant messaging server and may adversely impact the processing of other types of traffic.
Thus, principles of the invention provide for the processing of presence traffic in an on-demand (i.e., when requested) manner, i.e., the presence information is processed only when an instant messaging user explicitly requests the presence of her buddy. Note that an average instant messaging user can have a large number of buddies. She may not care about the presence of all of them most of the time. In addition, the presence information is refreshed periodically, i.e., a user can go online, offline, away, and come back. Hence, a piece of presence information can become obsolete before it is used by the instant messaging user.
There are several ways we can determine whether or not an instant messaging user wants to know the presence of her buddy. In one embodiment, the presence information is sent when a user clicks on the corresponding icon of her buddy. In another embodiment, the presence information is sent when a user moves her cursor over the icon of her buddy. In yet another embodiment, the presence information is sent when the icon of the buddy is displayed in the user's instant messaging window. This is useful if the user has several screens of buddies, not all of which can be displayed at the same time. In a further embodiment, the presence information is sent when a chat window is attempted to the buddy. In yet another embodiment, the presence information is sent when a group is expanded to reveal individual members. Instant messaging software can organize buddies into groups, e.g., friends, relatives, work, etc. When a group is collapsed, the individual members are not visible. When the group is expanded, those members become visible. Thus, in this particular embodiment, presence information is sent when the user chooses to expand a particular group to reveal individual members of that group. It is understood that the above are just examples and are not intended to limit the scope of the invention.
In an additional example, the instant messaging system may request user presence information based on recent and/or frequent communications. For example, if an instant messaging user has communicated with a particular buddy frequently in the near past, the system may request the presence information of that particular buddy more often than that of other buddies.
Principles of the invention also provide for offloading message processing to one or more proxies. Proxies can assist servers in the processing of instant messaging. In particular, nonessential traffic can be absorbed by proxies without ever reaching servers. Presence information can also be processed and stored at the proxies until it is requested by the user at which time it can be forwarded to the server for processing in an on-demand manner. The use of proxies is especially beneficial during server overload such as flash crowd events, or when the network is overloaded.
Data paths in the messaging system may include voice and video chats relayed by the servers and/or proxies when both parties in the conversations are behind firewalls or network address translators (NATs).
Thus, the computer system shown in
As shown, computer system 60 includes processor 61, memory 62, input/output (I/O) devices 63, and network interface 64, coupled via a computer bus 65 or alternate connection arrangement.
It is to be appreciated that the term “processor” as used herein is intended to include any processing device, such as, for example, one that includes a CPU and/or other processing circuitry. It is also to be understood that the term “processor” may refer to more than one processing device and that various elements associated with a processing device may be shared by other processing devices.
The term “memory” as used herein is intended to include memory associated with a processor or CPU, such as, for example, RAM, ROM, a fixed memory device (e.g., hard drive), a removable memory device (e.g., diskette), flash memory, etc.
In addition, the phrase “input/output devices” or “I/O devices” as used herein is intended to include, for example, one or more input devices (e.g., keyboard, mouse, etc.) for entering data to the processing unit, and/or one or more output devices (e.g., display, etc.) for presenting results associated with the processing unit.
Still further, the phrase “network interface” as used herein is intended to include, for example, one or more transceivers to permit the computer system to communicate with another computer system via an appropriate communications protocol.
Accordingly, software components including instructions or code for performing the methodologies described herein may be stored in one or more of the associated memory devices (e.g., ROM, fixed or removable memory) and, when ready to be utilized, loaded in part or in whole (e.g., into RAM) and executed by a CPU.
In any case, it is to be appreciated that the techniques of the invention, described herein and shown in the appended figures, may be implemented in various forms of hardware, software, or combinations thereof, e.g., one or more operatively programmed general purpose digital computers with associated memory, implementation-specific integrated circuit(s), functional circuitry, etc. Given the techniques of the invention provided herein, one of ordinary skill in the art will be able to contemplate other implementations of the techniques of the invention.
Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be made by one skilled in the art without departing from the scope or spirit of the invention.
