Abstract:
A streaming server which streams an application to a client computer (“endpoint”), as well as the client on which the streamed application runs, makes predictions as to what sections of the application the client is likely to execute in the future. Upon receipt of an indication (e.g., from a system administrator) of a planned service outage of the server or the network, the server transmits the application content that is predicted to be needed by the client during the outage in order to continue executing the application without interruption. The client receives and caches the content. Provided that the prediction is sufficiently accurate, the client can continue to seamlessly execute the application during the service outage.

Description:
TECHNICAL FIELD 
     This invention pertains generally to application streaming technology, and more specifically to adapting application streaming to proactively manage planned disruptions. 
     BACKGROUND 
     Application streaming provides the ability for an endpoint (e.g., a client computer) to run an application locally that is stored remotely, for example on a server. The server transmits specific portions of the application (e.g., code pages) to the endpoint, as the endpoint needs them. Application streaming offers a number of advantages over running the application on the server. Streaming the application allows the application to execute locally on the endpoint, instead of remotely on the server. This eliminates the need for large farms of servers to provide applications to a plurality of client computers. Application response time to the user is also significantly faster when the application is run locally on the endpoint, as opposed to remotely on the server. Commercial application streaming technology exists today. 
     Because the application content is streamed from a server to a client via a network, application streaming is dependent upon the availability of the server and network. However, servers and networks sometimes require maintenance (e.g., server replacement, network switch over, etc.) which require that they be temporarily taken out of service. When the network or the server need to undergo any temporary disruption, this has the effect of termination or pausing of any corresponding streamed applications on the endpoint. This is clearly not desirable. 
     It would be desirable to be able to be able to adapt application streaming to proactively manage planned outages of the server or network. 
     SUMMARY 
     A streaming server which streams an application to a client computer (“endpoint”), as well as the client on which the streamed application runs, makes predictions as to what sections of the application the client is likely to execute in the future. Upon receipt of an indication (e.g., from a system administrator) of a planned service outage of the server or the network, the server transmits the application content that is predicted to be needed by the client during the outage in order to continue executing the application without interruption. The client receives and caches the content. Provided that the prediction is sufficiently accurate, the client can continue to seamlessly execute the application during the service outage. 
     The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram illustrating a system for adapting application streaming to proactively manage planned service disruptions, according to some embodiments of the present invention. 
     
    
    
     The Figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein. 
     DETAILED DESCRIPTION 
       FIG. 1  illustrates a system  100  for adapting application streaming to proactively manage planned service disruptions, according to some embodiments of the present invention. It is to be understood that although various components are illustrated in  FIG. 1  as separate entities, each illustrated component represents a collection of functionalities which can be implemented as software, hardware, firmware or any combination of these. Where a component is implemented as software, it can be implemented as a standalone program, but can also be implemented in other ways, for example as part of a larger program, as a plurality of separate programs, as a kernel loadable module, as one or more device drivers or as one or more statically or dynamically linked libraries. 
     As illustrated in  FIG. 1 , application content  101  is streamed from a server  103  to an endpoint  105 , such that the streamed application  107  is executed on the endpoint  105 . In addition to standard application streaming functionality, a predictive agent  109  predicts what application content (e.g., code pages and appropriate metadata)  101  the endpoint  105  is likely to execute in the future. A variety of techniques are known to those of ordinary skill in the relevant art for predicting a path of execution. For example, this can be done both through call graph analysis within local code pages  101 , through historical profiling of the application  107 , and by maintaining per client  105  usage history of the application  107 . The implementation mechanics of such execution prediction methodologies are known to those of ordinary skill in the relevant art, and the use thereof within the context of the present invention will be readily apparent those of such a skill level in light of this specification. 
     As illustrated, a predictive agent  109   client  can run on the client  105 , and assist in predicting what code pages  101  may be needed for execution of the application  107  in the future, as described above. The resulting predictive information  111  is transmitted to the server  103 , either upon request or periodically. 
     A predictive agent  109   server  can also perform a similar function on the server  103 . The resulting predictive information  111  can be combined with predictive data  111  from the client  105 , to create a prediction of what code pages  101  are likely to be needed for the continuing execution of the application  107  on the endpoint  105 . It is to be understood that it is a design choice whether to gather predictive data  111  on the client  105 , the server  103  or both. As will be readily apparent to one of ordinary skill in the art in light of this specification, some types of data  111  are most efficiently gathered at the client end  105  (e.g., historical profiling of the execution of the application  107  on that client  105 ), some at the server end  103  (e.g., maintaining per client  105  usage history of the application  107  for a plurality of clients  105 ) and some can be effectively performed at either location (e.g., call graph analysis). As noted, which analysis to perform at which location is a variable design parameter. 
     Armed with information  111  concerning what code pages  101  a streamed application  107  is likely to execute in the future, a streaming agent  113  on the server  103  can adjust its streaming of that application  107  to prepare for planned outages of the server  103  or network  115 . System administrators  117  and the like are often aware of server  103  or network  115  service interruptions ahead of time. In such cases the administrator  117  can send an appropriate indication  119  to the streaming agent  113  that an interruption is to take place at a given time, with an estimate of the duration. The relevant predictive data  111  is used to make an estimate of what code  101  will be needed by the endpoint  105  for execution during the service outage. The streaming agent  113  pushes that code  101  from the server  103  to the client  105 , before the outage occurs. Once the server  103  and/or network  115  is returned to service, the streaming agent  113  can resynchronize with the client  105 . 
     It is to be understood that the predictive analysis can be used to determine a plurality of potential execution paths for the application  107 . For example, suppose the execution of a streamed code page  101  presents the user with a menu with three choices. In this example, hypothesize that the predictive analysis determines that the first of the three choices is never selected, but that it is equally likely that the user will select either the second choice or the third choice on the menu. Thus, although it would not be desirable to stream the code  101  for the execution for all three possible execution paths, it would be desirable to stream the code pages  101  associated with both the second and third choices, to ensure that the endpoint  105  has the code it needs. Additionally, it is to be understood that the predictive analysis typically takes into account the estimated length of time of the outage (this information is provided in the outage indication  119 , as discussed above). If the outage is to be short, the predictive analysis need not traverse the potential paths of execution too deeply. However, if the outage is to last a long time, code pages  101  traversing far deeper into the various potential execution paths are streamed. 
     More specifically, as illustrated in  FIG. 1 , a streaming agent  113  on the server  103  adjusts how application content  101  is sent to the endpoint  105 , responsive to receiving an indication  119  of an upcoming service outage. Rather than simply pushing a stream of code pages  101  to the client  105  as usual, the streaming agent  113  proactively sends additional application content  101  based on the predictive profile  111  discussed above. Code pages  101  to send proactively are selected based on likelihood of their execution by the endpoint  105  during the service outage. In other words, the streaming agent  113  sends the client  105  the code  101  the client  105  is predicted to execute during the outage, based on the predictive data  1111  for the client  105 . The client  105  caches this application content  101  as described below, for possible execution during the service outage. If the prediction is sufficiently accurate, the endpoint  105  has all the application content  101  it needs to continue seamlessly executing the application  107  during the outage. If the client  105  needs to execute code  101  it does not have, it can fall back to its normal failure mode, and terminate or suspend execution of the application  107  until the server  103  and/or network  115  is back online. 
     As  FIG. 1  illustrates, a caching agent  121  runs on the endpoint  105 . Above and beyond standard streaming application endpoint  105  caching functionality, the caching agent  121  is configured to handle a dynamic cache range. Instead of simply handling a static amount of “linear” cache, the agent  101  handles a dynamic amount of “branching” cache. More specifically, because it is not known precisely which code pages  101  will be executed by the endpoint  105  during the service outage, the caching agent  121  has the capacity to store a variable amount of application content (code pages)  101 . Additionally, for this same reason, the caching agent  121  is configured to store multiple possible code pages  101  without positive indication of which pages  101  will actually be executed. This way, the various code pages  101  that have been predicted to be executed during the service outage are cached and available to the endpoint  105 . As noted above, provided that the estimate is sufficiently accurate, the endpoint  105  has all the application content  101  required to continue executing the application  107  during the outage. The implementation mechanics of the above described caching functionality are known to those of ordinary skill in the relevant art, and the use thereof within the context of the present invention will be readily apparent to those of such a skill level in light of this specification. 
     As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies and other aspects of the invention can be implemented as software, hardware, firmware or any combination of the three. Of course, wherever a component of the present invention is implemented as software, the component can be implemented as a script, as a standalone program, as part of a larger program, as a plurality of separate scripts and/or programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Furthermore, it will be readily apparent to those of ordinary skill in the relevant art that where the present invention is implemented in whole or in part in software, the software components thereof can be stored on computer readable media as computer program products. Any form of computer readable medium can be used in this context, such as magnetic or optical storage media. Additionally, software portions of the present invention can be instantiated (for example as object code or executable images) within the memory of any programmable computing device. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.