The present invention generally relates to communication systems, nodes, devices, software and methods and, more particularly, to mechanisms and techniques for synchronizing updates of client applications.
Many applications which run on end-user devices (e.g., personal computers, mobile phones, PDAs, etc.) are networked these days. While some applications require or permit user-initiated downloading of data from the web, there are many applications that frequently poll servers for more data, status updates, or notifications. Such data can also be pushed to clients, typically via long-hanging HTTP poll techniques, a.k.a. COMET technology. Some such applications include RSS readers, Facebook clients, instant-messaging (IM) and email/pushmail clients, just to name a few.
Typically, such networked client applications poll their respective servers periodically, e.g., every few minutes. Often, the user is able to configure the poll interval in the settings of the application client, e.g., to set the polling interval to be every minute, every few minutes, every 10 minutes, etc. If a device is running many such client applications, then there might be a poll request transmitted by that device every minute even if the polling interval for each of the client applications is greater than 10 minutes, i.e., due to the large number of applications polling their respective servers. Thus, the number of sporadic traffic events (transmit and receive) might therefore be very high, even if there are relatively few status updates being made by the respective services associated with the client applications.
As an alternative to polling, push mechanisms using long-hanging HTTP polls or WebSockets have been suggested and deployed, for example in Apple's iPhone PushNotification mechanism. In other updating techniques, only a single TCP connection is established towards a gateway. HTTP GET requests are issued, and not returned by the server, until there is an event on the server, or a timeout has occurred. For low activity traffic, this results in very little sporadic traffic over the network, and if the timeouts in the operator gateways, firewalls and NATs are set appropriately, one can have a system with short delivery time, but with low power consumption. However, this approach requires a centralized server side, and changes to the client and server protocols, and can lead to high power consumption if there is frequent sporadic traffic. For example, an update with every twitter tweet, can lead to updates every minute or more.
For fixed Internet connections, the traffic patterns resulting from these polls and pushes are normally not a problem. However, for cellular networks and mobile end user devices, each network activity typically results in a corresponding drain on the device's battery as the radio is turned on and stays on for some time, which leads to a relatively high overhead in this process. For some users and Circumstances, a short notification time may be more important than a long battery life, but in many cases battery life-time is more important.
Thus, this situation poses potentially significant problems when the client device (and its multiple polling applications) communicate with the various servers via an air interface, i.e., a radio link, e.g., for mobile phones running such applications. For such devices, each time the device has to “wake up” from a lower power state to transmit a polling request, power is used from its battery. Moreover, the limited air interface resources are consumed by the corresponding network signaling associated with the device's wakeup. Consider
Therein, a first client application (App1) has a polling periodicity of 20 minutes. Thus, for example, App1 requests the device to send a polling request message to its respective server at time t=1 and then later at time t=21. If asleep, the device transitions from sleep mode, performs the necessary network handshaking, transmits a polling request over an air interface for App1, potentially awaits a response and then re-enters sleep mode. App 2, App 3, App 4 and App 5 (which are also running on the same device as App 1) have polling periodicities of ten minutes and perform the same operations as described above for App1 at time instants t=3 and t=13, t=5 and t=15, t=7 and t=17 and t=9 and t=19, respectively. Thus, as shown in the “Radio Activity” line of the histogram of
Of course it will be appreciated that the example shown in
Accordingly, it would be desirable to provide devices, systems, methods and software which address this problem.
The following exemplary embodiments provide a number of advantages and benefits relative to existing client application updating software, devices and methods including, for example, the possibility to reduce the number of times during which a device, e.g., including a radio transceiver, is operative to transmit polling requests. It will be appreciated by those skilled in the art, however, that the claims are not limited to those embodiments which produce any or all of these advantages or benefits and that other advantages and benefits may be realized depending upon the particular implementation.
According to one exemplary embodiment, a device includes a processor configured to simultaneously execute multiple applications each of which periodically receive updates from respective servers and to execute a central scheduling function which periodically transmits a polling event message to the multiple applications, and a communication interface configured to transmit, in response to the polling event message, a plurality of polling signals from the device, the polling signals being associated with the multiple applications which received the polling event message.
According to another exemplary embodiment, a method for polling servers from a device includes the steps of receiving, at multiple applications which are running simultaneously on the device, a polling event message, and transmitting, in response to the polling event message, a plurality of polling signals from the device, the polling signals being associated with the multiple applications which received the polling event message.
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. In the drawings:
The following description of the exemplary embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims. The following embodiments are discussed, for simplicity, with regard to the terminology and structure of presence systems described below. However, the embodiments to be discussed next are not limited to these systems but may be applied to other existing communication systems.
Reference throughout the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.
According to exemplary embodiments, a central update scheduling function is provided within the client device which synchronizes the update traffic associated with client applications, so that there are relatively infrequent, but well-used intervals when the radio is used, i.e., so that such update or polling traffic is less sporadic. Consider for example, an exemplary embodiment associated with the polling traffic in the context of the client device of
In this example, the client device 200 includes a wireless transceiver (not shown in
In this example, each client application App1-App5 periodically requests updates from a respective server 202, 204, 206, 208 and 210. Request signals are transmitted wirelessly over an air interface to a transceiver (not shown) in the server. Responsive updates are sent to the client device 200 as signals over the same air interface. More details regarding exemplary server equipment are provided below with respect to
According to an exemplary embodiment, in order to synchronize the polling requests, each of the client applications App1-App5 subscribes to a central scheduling function, shown as the pollingTimeNotification function 300 in
As mentioned above, the central scheduler function 300 can be implemented as software and/or hardware in the client device 200 and, according to this exemplary embodiment, broadcasts individual pollingTimeNotification event messages at regular intervals, for example every 10 minutes. Those skilled in the art will appreciate that the specific periodicity selected for the central scheduling function 300 to transmit a polling event message to its subscribed client applications can vary from implementation to implementation. Additionally, the actual period used can be fixed per implementation, or may vary over time per implementation, e.g., based on received information from each subscribing client application. In the latter case, the central scheduling function could select the periodicity based on, e.g., an average of the received preferred periodicities received in the subscription messages from the subscribing applications, a weighted average of the preferred periodicities, the least frequent preferred periodicity or the most frequent preferred periodicity.
When a subscribing application receives a polling event signal or message, the notified application can then perform polling, e.g., by transmitting a message to the client device 200's processor to wakeup the transceiver (both elements illustrated and described below with respect to
The foregoing exemplary embodiment illustrates an example of handling polling (pull) updates. However the present invention is not so limited. For push notifications, traffic aggregation, can also be performed on the server side.
As mentioned above, according to an exemplary embodiment, the pollTimeNotification center or function 300 notifies all subscribing applications about the appropriate time for polling. As shown in
Alternatively, as shown in
Usage of controlled polling mechanisms according to these exemplary embodiments may be mandated, e.g., each client application automatically subscribes when it is launched, or may be optional, e.g., each user has the option of using the central scheduler for a particular application or not, however it will be appreciated that the largest savings in terms of power and other resources are achieved if all applications obey this mechanism. It may therefore be advantageous to bind this mechanism to a way of measuring and presenting the network usage, or alternatively, to the battery drain due to network usage of each application to the user. The user can then detect which applications do not behave well, and disable these, e.g., force them to submit to the central scheduler. To save even more power, the system can be disabled when the client device 200 is in a sleep mode, and the central scheduling function 300 can be enabled to send polling events only in the periods when the client device is awake. In the Android framework, the pollTimeNotification could be realized using a broadcast Intent.
According to another exemplary embodiment, in a browser environment where applications are written in JavaScript, the pollTimeNotification service could be exposed as a global object on which the application could register for events that would be dispatched when it is appropriate to poll. These events could both be dispatched in parallel as well as in sequence (synchronously) in all active applications that have registered for the events.
The pollTimeNotification function 300 can be programmed to be informed about any other data transmission/reception which is ongoing, e.g., from the IP stack or by directly being informed about the radio state being changed to an active state. When detecting such an event, the pollTimeNotification function 300 can inform the subscribing applications that it is time to poll, even if the timer for polling has not yet expired. In this way, polling can piggy-back on other activities that awaken the radio transceiver from a low power sleep mode into an awakened, higher power-consuming state. Examples of such activities could be the user requesting a webpage via the browser, the user starting another application or a push-enabled application receiving data via a push channel.
As mentioned above, when subscribing to the pollTimeNotification function 300, each application can indicate information associated with its desired polling periodicity, e.g., the maximum polling interval or periodicity with which it would like to be updated. The pollTimeNotification function 300 can then, for example, select a polling interval that is the minimum of the requested poll interval of all subscribing applications. Alternatively, a weighted mean of all the subscribing applications' requested poll intervals could be used as the interval for the pollTimeNotification service polling interval. The pollTimeNotification function 300 can also provide or expose a user interface which enables the user to change the poll interval, or the minimum allowed poll interval, in one place for all applications. This can allow the user to change the trade-off between battery saving and immediacy. A timer maintained by the pollTimeNotification function 300 can use a value which is established using any of the foregoing (or other) techniques to count down periods between sending polling event messages to the relevant client applications.
Battery drain is one of the main problems with networked applications, and with background network applications in particular in mobile devices. On the other hand, immediate notification is often not needed in a mobile device, since it can be hidden from view, e.g., in the user's pocket, a large part of the time, and therefore immediate presence notifications are not as useful as they are on a desktop PC. Exemplary embodiments provide a means to reduce the background battery consumption by coordinating otherwise sporadic poll traffic to occur in concentrated periods, rather than as random events. Power savings in wireless devices occur by, for example, by reducing the overhead of setting up the radio connection multiple times, and staying in an active radio state for a while after each connection activity.
To provide an incentive to use these exemplary embodiments, a monitor, can be provided e.g., displayed on a display of the client device 20, which shows the battery drain of the network activities of all applications. This may take into account the coordination effects of using one common radio establishment interval for multiple applications.
An exemplary client device 200 can be a mobile device such as the exemplary mobile computing arrangement 700 shown in
The processing unit 702 may control the basic functions of the mobile terminal as dictated by programs available in the storage/memory 704. Thus, the processing unit 702 may execute the functions described above with respect to
One of the programs that may be stored in the storage/memory 704 is a specific program 706. As previously described, the specific program 706 may be a client application which interacts with a respective server to obtain updates, and which can coordinate with a central scheduling function to determine when it can initiate an updating process (e.g., polling). The specific program 706 can also represent the central scheduling function itself. The program 706 and associated features may be implemented in software and/or firmware operable by way of the processor 702. The program storage/memory 704 may also be used to store data 708, such as the various authentication rules, or other data associated with the present exemplary embodiments. In one exemplary embodiment, the programs 706 and data 708 are stored in non-volatile electrically-erasable, programmable ROM (EEPROM), flash ROM, etc. so that the information is not lost upon power down of the mobile terminal 700.
The processor 702 may also be coupled to user interface 710 elements associated with the mobile terminal. The user interface 710 of the mobile terminal may include, for example, a display 712 such as a liquid crystal display, a keypad 714, speaker 716, and a microphone 718. These and other user interface components are coupled to the processor 702 as is known in the art. The keypad 714 may include alpha-numeric keys for performing a variety of functions, including dialing numbers and executing operations assigned to one or more keys. Alternatively, other user interface mechanisms may be employed, such as voice commands, switches, touchpad/screen, graphical user interface using a pointing device, trackball, joystick, or any other user interface mechanism.
The mobile computing arrangement 700 may also include a digital signal processor (DSP) 720. The DSP 720 may perform a variety of functions, including analog-to-digital (A/D) conversion, digital-to-analog (D/A) conversion, speech coding/decoding, encryption/decryption, error detection and correction, bit stream translation, filtering, etc. The transceiver 722, generally coupled to an antenna 724, may transmit and receive the radio signals associated with a wireless device.
The mobile computing arrangement 700 of
An example of a representative computing system capable of carrying out operations in accordance with, for example, the servers of the exemplary embodiments is illustrated in
The exemplary computing arrangement 800 suitable for performing the activities described in the exemplary embodiments may include server 801, which may correspond to any of servers shown in
The server 801 may also include one or more data storage devices, including hard and floppy disk drives 812, CD-ROM drives 814, and other hardware capable of reading and/or storing information such as DVD, etc. In one embodiment, software for carrying out the above discussed steps, e.g., receiving polling signals and transmitting corresponding updates, may be stored and distributed on a CD-ROM 816, diskette 818 or other form of media capable of portably storing information. These storage media may be inserted into, and read by, devices such as the CD-ROM drive 814, the disk drive 812, etc. The server 801 may be coupled to a display 820, which may be any type of known display or presentation screen, such as LCD displays, plasma display, cathode ray tubes (CRT), etc. A user input interface 822 is provided, including one or more user interface mechanisms such as a mouse, keyboard, microphone, touch pad, touch screen, voice-recognition system, etc.
The server 801 may be coupled to other computing devices, such as the landline and/or wireless terminals and associated watcher applications, via a network. The server may be part of a larger network configuration as in a global area network (GAN) such as the Internet 828, which allows ultimate connection to the various landline and/or mobile, client devices such as that illustrated in
Although the features and elements of the present exemplary embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flow charts provided in the present application may be implemented in a computer program, software, or firmware tangibly embodied in a computer-readable storage medium for execution by a general purpose computer or a processor. For example, according to an exemplary embodiment, a method for polling servers from a client device includes the steps illustrated in
According to another exemplary embodiment, and as described above, a scheduler operates to trigger multiple applications in a synchronized (or otherwise time-optimized) manner to perform network access (e.g., via the Internet) in order to reduce, for example, the total time of radio access and or the total number of times that a radio is turned on. The network connection can, for example, include a network connection which is used to poll a server for new, available data and then to download that data. Alternatively, the network connection can be used to upload content or synchronize content with a server, or another network entity.
The above-described exemplary embodiments are intended to be illustrative in all respects, rather than restrictive, of the present invention. All such variations and modifications are considered to be within the scope and spirit of the present invention as defined by the following claims. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items.
This application is related to, and claims priority from, U.S. Provisional Patent Application Ser. No. 61/287,454, filed on Dec. 17, 2009, entitled “Synchronization of Sporadic Web Poll Traffic”, the entire disclosure of which is incorporated here by reference.
Number | Date | Country | |
---|---|---|---|
61287454 | Dec 2009 | US |