Patent Application
20070118530
Users have access to a wide range of application modules that provide functionality when executed by a computing device. For example, an operating system may be utilized in conjunction with a plurality of other application modules to provide communication (e.g., email and instant messaging), productivity (e.g., word processing, spreadsheets, drawing, presentations, and so on), information retrieval (e.g., web browsing), and so forth. Because the users typically desire increased functionality from each of these application modules, programmers continually work to provide updates to the application modules. Distribution of these updates to the users, and more particularly the user's devices, however, may be difficult.
A traditional technique that was utilized to update application modules, for instance, distributed new versions of the application modules that were stored on computer-readable media (e.g., a CD-ROM), which was then purchased by the user. The user, when using this technique, manually loaded the new versions onto the computing device, which was both time consuming and resulted in user frustration. A technique that was developed to address these problems provided the software updates over a network, such as to expose software updates at a service that is accessible to the user over a network. However, this technique typically required each user to poll the service to determine whether an update was available. Accordingly, as the number of users increased, so too did the burden on the service which was targeted by the polling, even to the point where failures may be encountered due to overburdening of the service. Therefore, this technique may also result in user frustration and is burdensome not only to the user, but also the network and computing resources utilized to provide the updates.
Software updates are described. Provision of software updates for an application module may be scheduled such that different subsets of a plurality of clients are notified as to the availability of a software update at different times. For example, a group of clients, when polling to determine whether an update is available, may receive an indication that the update is not available while another group of clients may receive an indication that it is available. In this way, a service which provides the updates may “throttle” how many clients receive the indications, and therefore manage a corresponding burden on the service in providing the updates. Notification of the software updates may also be incorporated within an authentication service such that a single request may be utilized to authenticate the client (e.g., the client's identity for accessing a service) as well as determine whether updates are available for the client.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
The same reference numbers are utilized in instances in the discussion to reference like structures and components.
Overview
Software updates are described. Traditionally, software updates that were provided over a network required each user to poll the service to determine whether an update was available. Accordingly, as the number of users increased, so too did the burden on the service which was targeted by the polling, even to the point where failures may be encountered due to overburdening of the service. For example, a release of a new software update for a popular application module (e.g., an instant messaging module) may result in millions of attempts by user's to obtain the update in a relatively short amount of time. Therefore, a provider of the update may encounter update errors due to the large amount of resources that are to be utilized to provide these updates over those typically used in day-to-day operation. In an attempt to avoid these errors, the provider may obtain additional resources (e.g., hardware resources, network bandwidth, and so on) to address this increased demand, which may be costly and inefficient.
In an implementation, provision of software updates for an application module is scheduled such that different subsets of a plurality of clients are notified as to the availability of a software update at different times. For example, a group of clients, when polling to determine whether an update is available, may receive an indication that the update is not available. During a corresponding period of time, however, another group of clients may receive an indication that the update is available. In this way, a service that provides the updates may “throttle” how many clients receive the indications, and therefore manage a corresponding burden on the service in providing the updates. In other words, the service may “spread out” when users receive the updates, further discussion of which may be found in relation to
In the following discussion, an exemplary environment is first described which is operable to implement the software update techniques. Exemplary procedures are then described which may be employed in the exemplary environment, as well as in other environments.
Exemplary Environment
Although the network 106 is illustrated as the Internet, the network 106 may assume a wide variety of configurations. For example, the network 106 may include a wide area network (WAN), a local area network (LAN), a wireless network, a public telephone network, an intranet, and so on. Further, although a single network 106 is shown, the network 106 may be configured to include multiple networks. For instance, client 104(1) may be communicatively coupled directly to the update service 102 via the Internet, while client 104(N) is communicatively coupled to the update service 102 via a dial-up connection to an Internet service provider. A wide variety of other instances are also contemplated without departing from the spirit and scope thereof.
Each of the plurality of clients 104(1)-104(N) is illustrated as including a respective one or more of a plurality of application modules 108(1)-108(N). Application modules 108(1)-108(N) are executable on the respective clients 102(1)-102(N) to provide a variety of functionality. For example, one or more application modules 108(1)-108(N) may be configured to send and receive email. Email employs standards and conventions for addressing and routing such that the email may be delivered across the network 106 utilizing a plurality of devices, such as routers, other computing devices (e.g., email servers), and so on. In another example, one or more of the application modules 108(1)-108(N) may be configured to provide one or more business productivity functions such as word processing, database, spreadsheet, and presentation functionality. In a further example, application modules 108(1)-108(N) may be configured to provide one or more software development functions such as development interfaces, tools, management, and compilation. Further, the application modules 108(1)-108(N) may provide other computing functions such as graphic design, web browsing, and media management, editing, viewing, and/or playback.
In yet another example, the application modules 108(1)-108(N) may be configured to send and receive instant messages. Instant messaging provides a mechanism such that a plurality of clients 104(1)-104(N), when participating in an instant messaging session, may send text messages to each other. Instant messages are typically communicated in real time, although delayed delivery may also be utilized, such as by logging the text messages when one of the clients 104(1)-104(N) is unavailable, e.g., offline. Thus, instant messaging may be though of as a combination of e-mail and Internet chat in that instant messaging supports message exchange and is designed for two-way live chats for synchronous communication in real time. For instance, like a voice telephone call, an instant messaging session may be performed in real-time such that each user may respond to each other user as the instant messages are received. Although a range of functionality that may be employed by the instant messages has been described, a wide variety of other functionality may also be provided, such as an operating system and so forth.
As previously described, software developers may make continual improvements to the application modules 108(1)-108(N) and provide these improvements as software updates 110(m) (where “m” can be any integer from one to “M”), which are illustrated as stored in storage 112 of the update service 102. To manage the software updates 110(m), the update service 102 includes an update manger module 114 that is executable to store, locate and provide the software updates 110(m).
For example, each of the clients 104(1)-104(N) is illustrated as including a respective update module 116(1)-116(N) that is executable to automatically poll the update service 102 to determine whether a software update is available for the respective applications modules 108(1)-108(N). The update manager module 102, for instance, may determine whether a respective software update 110(m) is available by comparing version data 118(1)-118(N) of the application modules 108(1)-108(N) with version data 120(k) (where “k” can be any integer from one to “K”) stored in storage 122 at the update service 102. When a software update 110(m) is available, the update service 102 may notify the clients 104(1)-104(N) of this availability, each of which may then initiate a process in order to obtain the software updates 110(m).
However, as previously described the software updates 110(m) may be desired by a vast number of clients 104(1)-104(N) such that the provision of the software updates 110(m) may overtax the update service 102. For example, the application modules 108(1)-108(N) may be configured as instant messaging modules that are utilized by millions of respective clients 104(1)-104(N) to participate in instant messaging. If each of the millions of clients 104(1)-104(N) requested updates to the respective application modules 108(1)-108(N) in a relatively short amount of time, however, these requests may exceed the resource capabilities (e.g., hardware, software and/or network resources) of the update service 102 that is configured to provide the software updates 110(m). Therefore, the update service 102, through execution of the update manager module 114, may utilize an update schedule 124 to determine which of the clients 104(1)-104(N) may receive an update at a particular point in time.
The update schedule 124 may be configured in a variety of ways to control which clients 104(1)-104(N) are able to receive updates. For example, the update schedule 124 may be configured as an update ratio (e.g., three out of every ten requests are informed as to the existence of an update), request threshold (e.g., after receipt of “x” number of requests, the respective client is notified of the update), scheduled download (e.g., the client is “slotted” to a particular time, at which, the client is authorized to download the software update 110(m)), and so on, further discussion of which may be found in relation to the following figures. Thus, the update manager module 114 may “throttle” the number of software updates 110(m) that are provided in a particular amount of time, thereby “spreading out” the demand of the clients 104(1)-104(N) and conserving software resources of the update service 102, network 106, and clients 104(1)-104(N) themselves.
Generally, any of the functions described herein can be implemented using software, firmware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations. The terms “module,” “functionality,” and “logic” as used herein generally represent software, firmware, or a combination of software and firmware. In the case of a software implementation, the module, functionality, or logic represents program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs). The program code can be stored in one or more computer readable memory devices, further description of which may be found in relation to
Processors are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, processors may be comprised of semiconductor(s) and/or transistors (e.g., electronic integrated circuits (ICs)). In such a context, processor-executable instructions may be electronically-executable instructions. Alternatively, the mechanisms of or for processors, and thus of or for a computing device, may include, but are not limited to, quantum computing, optical computing, mechanical computing (e.g., using nanotechnology), and so forth. Additionally, although a single memory 210(s), 212(n)is shown, respectively, for the servers 204(s) and clients 104(n), a wide variety of types and combinations of memory may be employed, such as random access memory (RAM), hard disk memory, removable medium memory, and other computer-readable media.
The authentication service 202 includes an authentication manager module 214 that is representative of functionality to authenticate identity of the clients 104(n). In other words, the authentication manager module 214 may be executed to verify that the clients 104(n) “are who they say they are”. Additionally, an indication of this authentication may be provided to one or more other service providers 216(p) (where “p” can be any integer from one to “P”) to enable the client 104(n) to access the service providers 216(p) through a single “logon”. For example, the client 104(n), through execution of the application module 108(n), may communicate over the network 106 with the authentication service 202 and provide authentication data (e.g., client name and password) to the authentication manager module 214. The authentication manager module 214 is executable to verify the authentication data received from the client 104(n) using authentication data 218(a) that is stored in storage 220 that corresponds to the client 104(n).
When verified, the authentication manager module 214 is also executable to provide an indication (e.g., a token) that the verification was successfully performed to the client 104(n). The client 104(n) may then provide this indication (e.g., the token) to the service providers 216(p) when attempting access. Thus, the service providers 216(p) may be configured to recognize the indication, but need not be configured to perform the authentication themselves, thereby “offloading” the authentication process to the authentication service 202. A wide variety of other authentication examples are also contemplated without departing from the spirit and scope thereof, such as through communication between the service providers 216(p) and the authentication service 202 when the client 104(n) attempts access to verify that the authentication has been performed.
The authentication service 202 in this instance incorporates the functionality of the update service 102 of
The provision of updates from the authentication service 202 to the clients 104(n) may also be managed through use of the update schedule 124 as previously described in relation to
By coupling the updates (and more particularly the update schedule 124) to the authentication service 202, however, the authentication service 202 may manage the updates by providing directives in an authentication response as to whether the client 104(n) should retrieve the software update. Therefore, the authentication service 202 may “throttle” the number of software updates 110(m) that are provided during a period of time as well as reduce latency traditionally experienced by the client when performing dedicated “polling” of the service for updates. Additionally, the software update 110(n) may be downloaded during execution of the application module 108(n) in the “background” and implemented a subsequent time the application module 108(n) is initiated, thereby keeping the implementation of the software update 110(n) from interfering with the execution of the application module 108(n). Further discussion of software updates may be found in relation to the following exemplary procedures.
It should be noted that although separate modules have been illustrated to depict the functionality represented by the modules in
Exemplary Procedures
The following discussion describes update techniques that may be implemented utilizing the previously described systems and devices. Aspects of each of the procedures may be implemented in hardware, firmware, or software, or a combination thereof. The procedures are shown as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks. In portions of the following discussion, reference will be made to the environment 100 of
The update manager module 114, for instance, may compare version data 118(1) received in the request with version data 120(k) to determine whether an update is available (decision block 306). When an update is not available (“no”) from decision block 306), a response is formed for communication to the client that indicates that an update is not available (block 308). Therefore, in this instance, an update is not available and therefore the client is provided an accurate indication of the unavailability.
When an update is available (“yes” from decision block 306), a determination is made as whether to indicate that the update is available based on an update schedule (block 310) and therefore determine whether to indicate that the update is available to the client (decision block 312). If so (“yes” from decision block 312), a response is formed for communication to the client that indicates that an update is available (block 314). If not (“no” from decision block 312), a response is formed for communication to the client that indicates that an update is not available (block 308).
For example, the update schedule may be configured as an update ratio such that, for every “x” number of requests, “y” number of responses are sent that indicate the update is available, where “y” is less than “x”. Therefore, by setting “x” and “y”, the update service 102 may manage how many clients are informed as to the availability of the updates, and therefore are provided with an opportunity to obtain the updates. In this way, the update service 102 may manage the provision of the software updates 110(m) even to “polling” clients. This management may also be performed dynamically, such that as fewer requests (i.e., “x”) are received over a period of time, a greater number of responses (e.g., “y”) are sent that indicate the availability of the update. The update schedule may also be configured in a variety of other ways to manage (i.e., “throttle”) prevision of the software updates, such as by also incorporating a threshold number of times particular clients request an available update before being given access to the update.
The authentication service then determines whether to update the at least one application module (block 406). The update manage module 114, for instance, may be executed by the authentication service 202 to determine whether an update is available and whether to inform the client of the availability of the update, such as through use of the update schedule 124 as described previously in relation to
A response is formed for communication to the client based on the determination and that includes a token that verifies authentication (block 408). The response, for instance, may indicate that an update is available based on an update ratio specified by the update schedule 124, a request threshold, a download schedule, and so on The response may also include a token which may be utilized by the client to access another service provider 216(p). For example, the token may enable the client 104(n) to access a website, an instant messaging service, online banking, and so on without resubmitting the authentication data, e.g., the client name and password.
The update is then retrieved based on the response (block 410). The response, for example, may include a network address of where to initiate a download of the update, may include the update itself, and so on. Additionally, update retrieval may be monitored and used to adjust the update schedule accordingly (block 412). For instance, a provider of the update (e.g., the authentication service 202) may monitor resource usage when providing the updates and use this monitoring to adjust the update schedule according to whether resources are or are not available. Thus, the resources used to provide the updates may be managed through use of the update schedule. A variety of other instances are also contemplated without departing from the spirit and scope thereof.
Conclusion
Although the invention has been described in language specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed invention.
