Patent Application
20070112954
The present invention relates generally to network communications, and more particularly, but not exclusively, to a system and method for managing a detection of an abnormal client termination using an automatically determined heartbeat value that is based, in part, on a client state.
In today's networking infrastructures, a client-server implementation is a commonly used networking application architecture. In the client-server implementation, the client is typically separate from the server. This implementation is a very scalable approach that may be arranged to allow a single server to service requests from many clients. When a client makes a connection to the server, it may consume a portion of the server's resources. When a client is ready, it may provide a connection termination request to the server acknowledging that it no longer requests the server's resources. In some instances, the server may then record how much of the resources were consumed. This record may be useable for such activities as billing a client for its resource consumption.
However, when a client abnormally terminates, perhaps due to a client crash, power failure, network failure, or the like, the server may not then know that the resources are no longer being requested by the client. This may sometimes result in the resource being allocated to the client beyond the abnormal termination. Such allocation results in wasting of server resources. In addition, it may also result in an improper recording of the client's consumption of the resources. Thus, it is with respect to these considerations and others that the present invention has been made.
Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following drawings. In the drawings, like reference numerals refer to like parts throughout the various figures unless otherwise specified.
For a better understanding of the present invention, reference will be made to the following Detailed Description of the Invention, which is to be read in association with the accompanying drawings, wherein:
The present invention now will be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments by which the invention may be practiced. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Among other things, the present invention may be embodied as methods or devices. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.
Throughout the specification and claims, the following terms take the meanings explicitly associated herein, unless the context clearly dictates otherwise. The phrase “in one embodiment” as used herein does not necessarily refer to the same embodiment, though it may. As used herein, the term “or” is an inclusive “or” operator, and is equivalent to the term “and/or,” unless the context clearly dictates otherwise. The term “based on” is not exclusive and allows for being based on additional factors not described, unless the context clearly dictates otherwise. In addition, throughout the specification, the meaning of “a,” “an,” and “the” include plural references. The meaning of “in” includes “in” and “on.”
The terms “network connection” and “connection” refer to a collection of links, software elements, and communication protocols that enable a computing device to communicate with another computing device over a network. Establishing a connection may arise through a request for the connection using any of a variety of communication protocols. For example, one such network connection may be a TCP connection. TCP connections are virtual connections between two network devices, and are typically established through a TCP handshake protocol. The TCP protocol is described in more detail in Request for Comments 793, which is available at http://www.ietf.org/rfc/rfc0793.txt?number=793. The present invention however, is not limited to TCP network connections. For example, although known as a connectionless protocol, a UDP network “connection” can also be employed. Network connections may be employed to support various communication sessions. Such communication sessions may include, but are not limited to, VOIP sessions, IM sessions, SMS sessions, email sessions, videoconferencing sessions, streaming media sessions, or the like.
The term “client state” as used herein refers to a status, condition, process, transaction, or setting, of the client. One client state includes an idle state where the client may be viewed as not actively sending network packets over a network. Other client states include, but are not limited to being in a particular session, such as a VOIP session call, an IM session, an SMS session, or the like. In one mode, a start of a client state may be determined by a sending of a request to transition into that client state. For example, the VOIP session call client state may be said to be the current client state, when a VOIP call request is received by a server, and said to be no longer the current client state when a VOIP call cancel message is received by the server. In one embodiment then, the server may receive and maintain information indicating a client state, and/or a request to transition to a different client state.
As used herein, the term “heartbeat” refers to any periodic or quasi-periodic signal that may be employed to indicate a presence of the device sending the heartbeat signal. The sending device may use a variety of mechanisms to provide the heartbeat signal. For example, in one embodiment, the heartbeat signal may be a specially defined packet, a ping message, or the like. In one embodiment, the heartbeat signal is a TCP keep-alive packet.
Briefly stated, the present invention is directed towards a system, method, and apparatus for managing an abnormal client termination of a network connection with a server. When a client establishes a network connection with a server, the server provides various heartbeat values to the client. In one embodiment, the server may also send another heartbeat value to the client at various times while the client is still connected to the server, based on a variety of factors. Heartbeat values may be used to determine a frequency for sending a heartbeat signal to the server. Receipt of the heartbeat signal within a given frequency enables the server to determine, at least in part, whether the client has abnormally terminated.
The various heartbeat values may be based on a variety of factors, including, but not limited to, a network load at the server, a load at the server for a particular session type, a CPU load on the server, a number of active network connections being managed by the server, or other resource load. Moreover, the various heartbeat values may include a value for different states of the client, including various sessions, activities, or inactivity states. For example, in one embodiment, one heartbeat value may be used when the client is determined to be in an idle state. In another embodiment, another heartbeat value may be used to determine how often to send the heartbeat signal when the client is engaged in a VOIP session. The invention is not limited to these states, however. For example, the frequency of the heartbeat signal may be automatically modified by the client based on other states, including a videoconferencing session state, a streaming video state, or the like. When the client detects that it is in a different client state, the client may automatically employ a different heartbeat value based on the different client state. By employing different heartbeat values based, in part on a client state, and/or conditions monitored by the server, an improvement in the use of network resources may be achieved, including improvements in bandwidth, CPU resources, or the like. Moreover, by detecting an abnormal failure earlier, the invention may be able to terminate sessions sooner and thereby provide more accurate accounting information associated with sessions, and improve resource usage.
Illustrative Operating Environment
As shown in the figure, however, system 100 includes client devices 102-103, network 105, IM system 110, and VOIP system 112. IM system 110 may include IM connection servers 120, IM event servers 122, and IM user managers 124. VOIP system 112 includes relay server 131, SIP connection server 130, real-time event server 132, and user manager 134.
Client device 102 is in communication with IM connection servers 120, SIP connection server 130, and relay server 131 through network 105. Client device 103 is in communication with IM connection servers 120, SIP connection server 130, and relay server 131 through network 105. IM event servers 122 are in communication with IM connection servers 120 and IM user managers 124. Real-time event server 132 is in communication with SIP connection server 130 and user manager 134.
One embodiment of client devices 102-103 is described in more detail below in conjunction with
Typically, client devices 102-103 may be configured to communicate using any of a variety of protocols. For example, client devices 102-103 may be configured to employ RTP for communicating media data such as audio and video to another device. However, the invention is not so limited, and another media data mechanism may be employed, including IAX, and the like. Client devices 102-103 may also employ the SIP protocol for enabling setting up a session and enabling such actions as dialing a number, enabling a ring, a ring-back tone, busy signal, and the like. However, other signaling protocols may also be employed, including H.323, Skinny Client Control Protocol (SCCP), IAX, MiNET, and the like. Typically, however, client devices 102-103 may employ SIP over either UDP or TCP and RTP over UDP.
Client devices 102-103 may include a client application that enables a VOIP connection such that a VOIP call from another computing device may result in establishing an active VOIP session over a connection. The client devices in the active VOIP session may be said to be in a current client state of a VOIP session call.
Moreover, the client application may provide a message indicating that the VOIP session with the caller is active. In one embodiment, the client application may be an IM client application. In another embodiment, the client application is a component of an application, such as the IM client application, or the like. However, the invention is not so limited, and the client application may be a separate application that may also interact with an IM application, a VOIP application, or the like.
In addition, client devices 102-103 may also be configured to provide an identifier, sometimes known as an originating line identifier (OLI) during a communication. The identifier may employ any of a variety of mechanisms, including a device model number, a carrier identifier, a mobile identification number (MIN), and the like. The MIN may be a telephone number, a Mobile Subscriber Integrated Services Digital Network (MS-ISDN), an electronic serial number (ESN), or other device identifier. The OLI may also be an IP address associated with client devices 102-103. In one embodiment, the identifier is provided with each communication. In another embodiment, the identifier is provided by an end-user. In one embodiment, the identifier may be associated with a user.
Client devices 102-103 may also include another client application that provides a heartbeat signal to a server device indicating that a network connection with the server should be considered as alive. Such heartbeat signals may be used to minimize a likelihood that the server determines that the client device has abnormally terminated due to a variety of conditions, including power failures, a locked client application, a failed client device, a network failure, or the like. The client application may receive from a server device various heartbeat values each of which may be associated with a different client state. The application may then select a heartbeat value based, in part, on a client state, for use in setting a frequency in which to send the heartbeat signal.
Devices that may operate as client devices 102-103 include devices that typically connect using a wired communications medium such as personal computers, desktop computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, and the like. The set of such devices may also include devices that typically connect using a wireless communications medium such as cell phones, smart phones, pagers, walkie talkies, Personal Digital Assistants (PDAs), handheld computers, programmable consumer electronics, an IP phone, radio frequency (RF) devices, infrared (IR) devices, CBs, integrated devices combining one or more of the preceding devices, or virtually any mobile device, and the like. Similarly, client devices 102-103 may be any device that is capable of connecting using a wired or wireless communication medium such as a PDA, POCKET PC, wearable computer, and any other device that is equipped to communicate over a wired and/or wireless communication medium.
Network 105 is configured to couple one computing device to another computing device to enable them to communicate. Network 105 is enabled to employ any form of computer readable media for communicating information from one electronic device to another. Also, network 105 may include a wireless interface, and/or a wired interface, such as the Internet, in addition to local area networks (LANs), wide area networks (WANs), direct connections, such as through a universal serial bus (USB) port, other forms of computer-readable media, or any combination thereof. On an interconnected set of LANs, including those based on differing architectures and protocols, a router acts as a link between LANs, enabling messages to be sent from one to another. Also, communication links within LANs typically include twisted wire pair or coaxial cable, while communication links between networks may utilize analog telephone lines, full or fractional dedicated digital lines including T1, T2, T3, and T4, Integrated Services Digital Networks (ISDNs), Digital Subscriber Lines (DSLs), wireless links including satellite links, or other communications links known to those skilled in the art. Furthermore, remote computers and other related electronic devices could be remotely connected to either LANs or WANs via a modem and temporary telephone link. In essence, network 105 may include any communication method by which information may travel between computing devices.
The media used to transmit information in communication links as described above illustrates one type of computer-readable media, namely communication media. Generally, computer-readable media includes any media that can be accessed by a computing device. Computer-readable media may include computer storage media, communication media, or any combination thereof.
Additionally, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave, data signal, or other transport mechanism and includes any information delivery media. The terms “modulated data signal,” and “carrier-wave signal” includes a signal that has one or more of its characteristics set or changed in such a manner as to encode information, instructions, data, and the like, in the signal. By way of example, communication media includes wired media such as twisted pair, coaxial cable, fiber optics, wave guides, and other wired media and wireless media such as acoustic, RF, infrared, and other wireless media.
IM system 110 is configured to manage IM sessions between client devices employing an IM client application. IM system 110 may employ IM connection servers 120, IM event servers 122, and IM user managers 124 to manage one or more IM sessions. In one embodiment, IM connection servers 120, IM event servers 122, and IM user managers 124 may represent separate server processes operating with a single computing device. In another embodiment, IM connection servers 120, IM event servers 122, and IM user managers 124 may represent distinct processes operating across multiple computing devices. As such, IM system 110 may be implemented on a variety of computing devices including personal computers, desktop computers, multiprocessor systems, microprocessor-based devices, network PCs, servers, network appliances, and the like.
IM connection servers 120 are configured to receive a request to establish an IM session from an IM client, such as might be included within client devices 102-103, and the like. IM connection servers 120 may also receive from the IM client authentication information that may be employed to authenticate an end-user of the IM client. If the end-user is authenticated, IM connection servers 120 may enable the IM client to log into the IM session. IM connections servers 120 may also be configured to provide information about the established session to IM event servers 122.
IM connections servers 120 may also forward various request information from the IM client to IM event servers 122. Such request information may include, for example, a request to locate and communicate with another IM end-user.
IM event servers 122 are configured to receive the end-user's log in and other request information from IM connections servers 120.1M event servers 122 may request IM user managers 124 to store information about the IM client and end-user. IM user mangers 124 may employ a table, spreadsheet, file, database, and the like, to register the IM client, and on which IM connection server, within IM connection servers 120, the IM client is logged into. Thus, IM user managers 124 may store information about various IM conversations that may include such information as identifiers for end-users associated with an IM conversation, time information, account identifiers for the end-users, IM connection servers associated with an IM conversation, and so forth. As such, IM event servers 122 may also employ IM user managers 124 to determine which IM connection server, within IM connection servers 122, another end-user is logged into, and provide such information to IM connection servers 120, so that an IM session may be established between two or more IM end-users.
VOIP system 112 is configured to manage VOIP sessions between client devices using any of a variety of VOIP protocols. As shown, VOIP system 112 may be implemented in a single computing device, with each of the illustrated components operating as one or more processes with the single computing device. VOIP system 112 may also be implemented across multiple computing devices, with one or more of the illustrated components distributed across the multiple computing devices. As such VOIP system 112 may be implemented on a variety of computing devices including personal computers, desktop computers, multiprocessor systems, microprocessor-based devices, network PCs, servers, network appliances, and the like.
Relay server 131 is configured to manage messages, such as media messages between one computing device and another, such as client devices 102-103, and the like. Relay server 131 may, for example, receive a VOIP packet, such as a TCP/IP packet and relay it towards a destination device. Relay server 131 may also be configured to monitor flow congestion, quality of service characteristics, and the like, associated with a communication between itself and the destination device, and/or the source device. Devices that may operate as relay server 131 include personal computers, desktop computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, servers, firewalls, gateways, network address translators, bridges, routers, and the like.
SIP connection server 130 is configured to receive a request to establish a SIP connection from client devices 102-103, and the like. The requesting device may provide identification information to SIP connection server 130 that may be used, at least in part, to authenticate the request to establish the SIP connection. If the requesting device is authenticated, SIP connection server 130 may enable the requesting device to log into a connection. SIP connection server 130 may also provide information about the requesting device to real-time event server 132. Real-time event server 132 may be configured to receive the information and provide it to user manager 134 for storage.
SIP connection server 130 may receive a heartbeat signal from a client device to validate that the client device is still active and that its connection is not abnormally terminated. SIP connection server 130 may determine various client states that client devices 102-103 may be in. In one embodiment, SIP connection server 130 is provided with a pre-determined set of likely client states, including at least one default client state to cover unlikely client states.
SIP connection server 130 may also provide the heartbeat values to a client device when it initially connects to the server. However, the invention is not so limited, and the heartbeat values may also be sent to the client device based on a change in a condition, periodically, or the like.
SIP connection server 130 may then determine a heartbeat value for each of the various client states. For example, SIP connection server 130 may determine that a reasonable heartbeat value for a VOIP session call state is between about 30 seconds, while a heartbeat value for an idle client state might be about 13 minutes. However, the invention is not so limited, and a variety of other values may be selected as heartbeat values for idle and/or VOIP session call client states.
For example, SIP connection server 130 may determine a heartbeat value based on a network load, a CPU resource load, a number of clients currently active, or other resource load. Based on such resource load determinations, SIP connection server 130 may vary the heartbeat values. For example, in one embodiment, SIP connection server 130 may set the heartbeat value during one load condition at about 20 seconds, while at another load condition the heartbeat value may be set to about 30 seconds.
SIP connection server 130 may determine a state in which a client device is in, and based, in part, on the determined client state, monitor for a heartbeat signal to be received at a frequency associated with the determined client state. In one embodiment, SIP connection server 130 may store information associated with which state a client device is in. Use of the stored client state information may then be employed by SIP connection server 130 to determine whether the client device has changed its client state.
Although SIP connection server 130 is described as providing the heartbeat values, and monitoring for the heartbeat signals, the invention is not so limited. For example, other networked devices may also provide the heartbeat values, and/or monitor for the heartbeat signals. In one embodiment, different networked devices may be employed, one for providing the heartbeat values, and another for monitoring for the heartbeat signals, without departing from the scope or spirit of the invention.
User manager 134 may store the information in a database, spreadsheet, table, file, and the like. Such information may include, for example, an identifier associated with the requesting device, an end-user associated with the requesting device, an address associated with SIP connection server 130, and the like. User manager 134 may receive and manage such information for a plurality of requesting devices. User manager 134 may also provide information to real-time event server 132 about at least one other requesting device, such that SIP connection server 130 may enable a VOIP communication between one or more end-user devices, such as client devices 102-103, and the like. In one embodiment, the one or more end-user devices may employ relay server 131 to relay the VOIP communications between them. For example, SIP connection server 130 may provide a token, certificate, ticket, or similar authentication/authorization mechanism, to the one or more client devices. The one or more client devices may then provide the authentication/authorization mechanism to relay server 131 to establish the communications.
Illustrative Client Device
As shown in the figure, client device 200 includes a processing unit 222 in communication with a mass memory 230 via a bus 224. Client device 200 also includes a power supply 226, one or more network interfaces 250, an audio interface 252, a display 254, a keypad 256, an illuminator 258, an input/output interface 260, a haptic interface 262, and an optional global positioning systems (GPS) receiver 264. Power supply 226 provides power to client device 200. A rechargeable or non-rechargeable battery may be used to provide power. The power may also be provided by an external power source, such as an AC adapter or a powered docking cradle that supplements and/or recharges a battery.
Client device 200 may optionally communicate with a base station (not shown), or directly with another computing device. Network interface 250 includes circuitry for coupling client device 200 to one or more networks, and is constructed for use with one or more communication protocols and technologies including, but not limited to, global system for mobile communication (GSM), code division multiple access (CDMA), time division multiple access (TDMA), user datagram protocol (UDP), transmission control protocol/Internet protocol (TCP/IP), SMS, general packet radio service (GPRS), WAP, ultra wide band (UWB), IEEE 802.16 Worldwide Interoperability for Microwave Access (WiMax), SIP/RTP, or the like.
Audio interface 252 is arranged to produce and receive audio signals such as the sound of a human voice. For example, audio interface 252 may be coupled to a speaker and microphone (not shown) to enable telecommunication with others and/or generate an audio acknowledgement for some action. Display 254 may be a liquid crystal display (LCD), gas plasma, light emitting diode (LED), or any other type of display used with a computing device. Display 254 may also include a touch sensitive screen arranged to receive input from an object such as a stylus or a digit from a human hand.
Keypad 256 may comprise any input device arranged to receive input from a user. For example, keypad 256 may include a push button numeric dial, or a keyboard. Keypad 256 may also include command buttons that are associated with selecting and sending images. Illuminator 258 may provide a status indication and/or provide light. Illuminator 258 may remain active for specific periods of time or in response to events. For example, when illuminator 258 is active, it may backlight the buttons on keypad 256 and stay on while the client device is powered. Also, illuminator 258 may backlight these buttons in various patterns when particular actions are performed, such as dialing another client device. Illuminator 258 may also cause light sources positioned within a transparent or translucent case of the client device to illuminate in response to actions.
Client device 200 also comprises input/output interface 260 for communicating with external devices, such as a headset, or other input or output devices not shown in
Optional GPS transceiver 264 can determine the physical coordinates of client device 200 on the surface of the Earth, which typically outputs a location as latitude and longitude values. GPS transceiver 264 can also employ other geo-positioning mechanisms, including, but not limited to, triangulation, assisted GPS (AGPS), E-OTD, CI, SAI, ETA, BSS and the like, to further determine the physical location of client device 200 on the surface of the Earth. It is understood that under different conditions, GPS transceiver 264 can determine a physical location within millimeters for client device 200; and in other cases, the determined physical location may be less precise, such as within a meter or significantly greater distances.
Mass memory 230 includes a RAM 232, a ROM 234, and other storage means. Mass memory 230 illustrates another example of computer storage media for storage of information such as computer readable instructions, data structures, program modules or other data. Mass memory 230 stores a basic input/output system (“BIOS”) 240 for controlling low-level operation of client device 200. The mass memory also stores an operating system 241 for controlling the operation of client device 200. It will be appreciated that this component may include a general purpose operating system such as a version of UNIX, or LINUX™, or a specialized client communication operating system such as Windows Mobile™, or the Symbian® operating system. The operating system may include, or interface with a Java virtual machine module that enables control of hardware components and/or operating system operations via Java application programs.
Memory 230 further includes one or more data storage 242, which can be utilized by client device 200 to store, among other things, programs 244 and/or other data. For example, data storage 242 may also be employed to store information that describes various capabilities of client device 200. The information may then be provided to another device based on any of a variety of events, including being sent as part of a header during a communication, sent upon request, and the like.
Programs 244 may include computer executable instructions which, when executed by client device 200, transmit, receive, and/or otherwise process messages (e.g., SMS, MMS, IM, email, and/or other messages), audio, video, and enable telecommunication with another user of another client device. Other examples of application programs include calendars, contact managers, task managers, transcoders, database programs, word processing programs, spreadsheet programs, games, codec programs, and so forth. In addition, mass memory 230 stores browser client 246, IM client 270, VOIP client 272, and Heartbeat Signal Manager (HSM) 274.
Browser 246 may be configured to receive and to send web pages, web-based messages, and the like. Browser 246 may, for example, receive and display graphics, text, multimedia, and the like, employing virtually any web based language, including, but not limited to Standard Generalized Markup Language (SMGL), such as HyperText Markup Language (HTML), a wireless application protocol (WAP), a Handheld Device Markup Language (HDML), such as Wireless Markup Language (WML), WMLScript, JavaScript, and the like.
VOIP client 272 is configured to enable client device 200 to initiate, receive, and manage a VOIP session with another client device. VOIP client 272 may employ the SIP protocol for managing signaling, and RTP for transmitting the VOIP traffic (“media”). However, the invention is not so constrained, and any of a variety of other VOIP protocols may be employed including IAX which carries both signaling and voice data, H.323, SCCP, Megaco, MGCP, MiNET, Skinny Client Control Protocol (SCCP), and the like. VOIP client 272 is further configured to employ virtually any media codec to compress the media stream for communicating it over the network, including G.711, G.729, G.729a, iSAC, Speex, and the like. In one embodiment, SIP may be employed to enable a Session Description Protocol (SDP).
VOIP client 272 may be further configured to manage a flow of VOIP packets to and/or from another computing device. In one embodiment, VOIP client 272 may employ these components to provide the packets using RTP with Real-time Control Protocol (RTCP). VOIP client 272 may employ an RTCP report from a destination device to determine various qualities of communications, including flow control, congestion control, quality of service, and the like.
IM client 270 may be configured to initiate and manage an instant messaging session, including, but not limited to AOL Instant Messenger, Yahoo! Messenger, NET Messenger Server, ICQ, and the like. In one embodiment, IM client 270 is configured to employ a VOIP client, such as VOIP client 272 to integrate IM/VOIP features. Thus, in one embodiment, IM client 270 may employ SIP to establish media sessions with another computing device employing an IM/VOIP capable client, and RTP to communicate the media traffic. However IM client 270 is not so limited. For example, IM client 270 may also employ any of the following SIMPLE (SIP for Instant Messaging and Presence Leverage), APEX (Application Exchange), Prim (Presence and Instant Messaging Protocol), the open XML-based XMPP (Extensible Messaging and Presence Protocol), more commonly known as Jabber and OMA (Open Mobile Alliance)'s IMPS (Instant Messaging and Presence Service) created specifically for mobile devices, and the like.
HSM 274 may be arranged to provide heartbeat signals to one or more servers. The heartbeat signals may be sent using virtually any of a variety of mechanisms, including a dedicated network packet, a keep alive packet, a ping message, or the like.
HSM 274 may receive a plurality of heartbeat values from a server, where each of the heartbeat values may be associated with a different client state. In one embodiment, HSM 274 may receive at least one heartbeat value when client device 200 establishes a connection with the server. In another embodiment, HSM 274 may receive at least one heartbeat value at different times during the established connection with the server.
Based on a client state, HSM 274 may select a heartbeat value and send the heartbeat signal based on a frequency determined from the selected heartbeat value. When the client state changes HSM 274 may select a different heartbeat value based on the new client state. Thus, HSM 274 may send heartbeat signals to the server(s) at different frequencies, based on the client state. If client device 200 returns to a first client state, HSM 274 may employ the heartbeat value for the first client state and send heartbeat signals based on that value. HSM 274 may employ a process substantially similar to process 500 described below in conjunction with
In one embodiment, HSM 274 may also determine a plurality of heartbeat values based on various client states. In this instance, HSM 274 may provide the plurality of heartbeat values to the server.
Illustrative Server Environment
Server device 300 includes processing unit 312, video display adapter 314, and a mass memory, all in communication with each other via bus 322. The mass memory generally includes RAM 316, ROM 332, and one or more permanent mass storage devices, such as hard disk drive 328, tape drive, optical drive, and/or floppy disk drive. The mass memory stores operating system 320 for controlling the operation of server device 300. Any general-purpose operating system may be employed. Basic input/output system (“BIOS”) 218 is also provided for controlling the low-level operation of server device 300. As illustrated in
Server device 300 may also include an SMTP handler application for transmitting and receiving email. Server device 300 may also include an HTTP handler application for receiving and handing HTTP requests, and an HTTPS handler application for handling secure connections. The HTTPS handler application may initiate communication with an external application in a secure fashion.
Server device 300 also includes input/output interface 324 for communicating with external devices, such as a mouse, keyboard, scanner, or other input devices not shown in
The mass memory as described above illustrates another type of computer-readable media, namely computer storage media. Computer storage media may include volatile, nonvolatile, removable, and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Examples of computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computing device.
The mass memory also stores program code and data. One or more applications 350 are loaded into mass memory and run on operating system 320. Examples of application programs include email programs, schedulers, calendars, transcoders, database programs, word processing programs, spreadsheet programs, and so forth. Mass storage may further include applications such as Heartbeat Signal Detector (HSD) 360.
HSD 360 may be configured to provide a client device various heartbeat values each being associated with a different client state, and to monitor a heartbeat signal for detection of an abnormal client termination. HSD 360 may employ a variety of mechanisms to determine the heartbeat values for each client state, including, determining the heartbeat values based on a CPU load, a network client, a number of client connections, a client state, or other resource load.
HSD 360 may provide the various heartbeat values to the client when the client initially establishes a connection with a server device. HSD 360 may also provide at least one heartbeat value during the established connection based on a change in a condition, such as a change in a load, or the like. HSD 360 may provide one heartbeat value for one client state to one client device and a different heartbeat value for the same client state to a different client device. This may occur for a variety of reasons, including how often HSD 360 selects to send heartbeat values to client devices, or the like.
HSD 360 may then receive information indicating which client state a client is in, and based, in part, on that client state, monitor receipt of a heartbeat signal from the client to determine whether the heartbeat signals are received within an associated heartbeat value. In one embodiment, HSD 360 receives the client state information from another component of server device 300. However, HSD 360 may also receive the client state information from another server device, or even from the client itself.
In one embodiment, HSD 360 may employ a tolerance of acceptance upon its monitoring of the frequency of heartbeat signals to minimize false positive type of detections of abnormal client terminations. Such tolerance may vary based on a client state, a resource load, or the like.
HSD 360 may also receive information indicating that the client has changed to a different client state, and based, in part, on the new client state, monitor receipt of a heartbeat signal from the client based on a heartbeat value associated with the new client state. In one embodiment, HSD 360 may employ a process substantially similar to process 400 described below in conjunction with
Generalized Operation
The operation of certain aspects of the invention will now be described with respect to
As shown in
Processing then proceeds to block 404, where a heartbeat value is determined for each of the various client states. Such heartbeat values are usable to set a frequency in which a heartbeat signal is to be sent by a client. Determination of the heartbeat values may be based on a variety of factors, conditions, or the like. For example, in one embodiment, heartbeat values may be pre-determined based on default values, values selected based on engineering judgment, or the like. In another embodiment, the heartbeat values may be determined based on an environment, including a resource load, or a variety of other dynamic factors. Moreover, some heartbeat values may be based on dynamic factors, while other heartbeat factors may be static values. Thus, in one embodiment, at least some of the heartbeat values may dynamically change for a given client state over time, while others may be constant over a client connection.
Processing continues next to decision block 406 where a determination is made whether a client is connected. If a client has established a connection, processing flows to decision block 408; otherwise, processing returns to a calling process to perform other actions.
At decision block 408, a determination is made whether to send the heartbeat values to the client. Heartbeat values may be sent to the client when they change for a given client state, only at initial establishment of a client connection, periodically, or the like. In any event, heartbeat values are typically sent at least at the initial establishment of the client connection. Thus, if heartbeat values are to be sent, processing flows to block 410, where they are sent to the client. Otherwise, processing branches to block 412.
At block 412, a client state is determined. In one embodiment, client information may be sent by the client that may be employed to determine the client state. For example, in one embodiment, when a client sends a request for a VOIP call session, client state may be determined based on the receipt of the request, the establishment of the VOIP call, or the like.
Processing then moves to decision block 414, where monitoring is performed for a heartbeat signal from the client based on the client state. In one embodiment, the monitoring may employ a tolerance of acceptance around the heartbeat value for the client state, to minimize false positive. At decision block 414 at determination is made whether heartbeat signals are received within the frequency determined by the heartbeat value for the client state. In one embodiment, if two consecutive heartbeats are not received within the expected frequency, a determination may be made that the client has abnormally terminated its connection. If it is determined that the client has abnormally terminated its connection, processing flows to block 416; otherwise, processing loops back to block 404 to continue until the client connection is terminated (normally as detected at decision block 406 or abnormally as detected at decision block 414).
At block 416, when an abnormal termination is detected, client connections may be properly closed. For example, where the client was in a VOIP call state, and abnormal termination is detected, the server may perform actions that properly close the VOIP call, including, but not limited to, sending a message to one of the clients in the VOIP call, shutting down a connection, or the like. Processing then returns to the calling process to perform other actions.
Process 500 begins, after a start block, at block 502, when a network connection is established with a server. In a typical IM session, a client may establish a connection with an IM connection server, and a VOIP connection server, such as IM connection server 120 and SIP connection server 130 of
Processing then proceeds to block 504, where the client may receive various heartbeat values, each heartbeat value being associated with a different client state. Such client states may have been predetermined by a server based on a variety of mechanisms, including, a study of typical client states, supported client states, or the like. Moreover, receipt of the heartbeat values may occur after the connection with the server(s) are established. In one embodiment, at least one heartbeat value may be received by the client dynamically, in that the at least one heartbeat value may be sent more than once by the server(s). In addition, at least one heartbeat value may be received that is different for the same client state, replacing a previously sent heartbeat value for that client state.
Processing continues next to block 506, where a heartbeat value is selected based on a current client state (e.g., a first client state). The selected first heartbeat value associated with the first client state is then employed at block 508 to set a frequency for which a heartbeat signal is sent to the server(s).
Process 500 flows next to decision block 510, where a determination is made whether the client has changed its client state. A determination that the client has changed its state may be based on a variety of conditions. For example, when the client sends a SIP call request, that is received and acknowledged by the server, the client may be said to have changed its client state. When the client subsequently sends a SIP call cancel message that is similarly received and acknowledged by the server, the client is said to have again changed its client state. There are, of course a variety of other conditions that may result in a client state change, including, but not limited to sending a request for a SMS session, a request for a videoconference session, a request for streaming media, a transition to an inactive or idle mode by the client, or the like. In any event, if it is determined that the client has changed client state, processing loops back to block 504, where optionally updates to the heartbeat values may be received.
Alternatively, if at decision block 510, the client state is not changed, processing flows to decision block 512. At decision block 512, a determination is made whether the connection with the server(s) are normally terminated. A normal termination may occur where the client sends a message indicating that it is terminating the session. If the connection is normally terminated, processing returns to a calling process to perform other actions; otherwise, processing loops back to block 508.
It will be understood that each block of the flowchart illustration, and combinations of blocks in the flowchart illustration, can be implemented by computer program instructions. These program instructions may be provided to a processor to produce a machine, such that the instructions, which execute on the processor, create means for implementing the actions specified in the flowchart block or blocks. The computer program instructions may be executed by a processor to cause a series of operational steps to be performed by the processor to produce a computer implemented process such that the instructions, which execute on the processor to provide steps for implementing the actions specified in the flowchart block or blocks.
Accordingly, blocks of the flowchart illustration support combinations of means for performing the specified actions, combinations of steps for performing the specified actions and program instruction means for performing the specified actions. It will also be understood that each block of the flowchart illustration, and combinations of blocks in the flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified actions or steps, or combinations of special purpose hardware and computer instructions. Moreover, at least some of the blocks of the flowchart illustration, and combinations of some of the blocks in the flowchart illustration, can also be implemented using a manual mechanism, without departing from the scope or spirit of the invention.
The above specification, examples, and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.
