Predictive transmission of content for application streaming and network file systems

The performance and hence the user experience of just-in-time application streaming is significantly enhanced by predicting which sections of an application are likely to execute next, and transmitting those sections from the server to the endpoint. A control flow graph of the application is created and analyzed against the execution state of the application such that it can be predicated which code pages the application is likely to utilize next. This analysis can be performed on the server, endpoint or any combination of the two. The predicted code pages are proactively pushed and/or pulled such that the application can continue executing without delay. This significantly enhances the performance of application streaming and network file system technologies, and is especially beneficial for very performance sensitive applications.

TECHNICAL FIELD

This invention pertains generally to application streaming technology and network file systems, and more specifically to proactively transmitting application content to an endpoint based on a control flow graph and current application execution state.

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.

A network file system is a computer file system that supports sharing of resources such as files, printers and/or persistent storage over a computer network. Network file systems such as Andrew File System (AFS), NetWare Core Protocol (NCP), and Server Message Block (SMB, also known as Common Internet File System (CIFS)) exist today. Network file systems can share files, including executable files, between servers and endpoints.

An important performance measurement of a network file system is the amount of time needed to satisfy service requests. In conventional file systems, this time consists of a disk-access time and a small amount of CPU-processing time. But in a network file system, a remote access has additional overhead due to the distributed structure. This includes the time to deliver the request to a server, the time to deliver the response to the client, and for each direction, a CPU overhead of running the communication protocol software.

Both application streaming technologies and network file systems can be used to execute applications stored on a remote server on a local endpoint. However, current application streaming technologies and network file systems do not take into account what sections of a given executable file need to be pushed to the endpoint. This results in either poor performance or failure of the application. This is a particular problem for mobile users, who are often connected to the server from which the application is originating through a poor performing network, and for wireless users, whose network performance can significantly vary depending on signal strength and interference.

In many existing implementations of application streaming technologies and network file systems, an agent runs on the endpoint, monitors the execution of the application, and pulls code pages from the server when necessary. In such implementations, the agent typically leverages exceptions to obtain non-present code pages that are needed for application execution to continue. In other words, when the application running on the endpoint does not have a code page it needs, it throws an exception. Responsive to the exception, the agent pulls the needed code page from the server. The process of the application throwing exceptions and the agent responsively pulling missing code pages creates a significant performance delay. Typically, the agent caches the pages on the endpoint after they have been pulled. However, every time the application requires a non-present, non-cached code page, the exception, page pulling process is repeated. Additionally, whenever an application is updated or patched (which happens quite frequently), the agent must pull new blocks/binaries, and the application again suffers significant performance degradation.

In some implementations, there is no agent on the endpoint to monitor the application and pull required contents. Under these implementations, the server has to blindly push the application content irrespective of the execution pattern on the endpoint. This is obviously not desirable, because the application cannot execute until it has been completely pushed to the endpoint, or else the application fails intermittently when required sections are not yet available. This is often the case with existing network file systems, where the application execution is significantly delayed or slowed down till the entire application binary has been pushed to the endpoint.

It would be desirable to have application streaming technology and network file systems that do not have these problems.

SUMMARY

The performance and hence the user experience of just-in-time application streaming is significantly enhanced by predicting which sections of an application are likely to execute next, and transmitting those sections from the server to the endpoint. A control flow graph of the application is created and analyzed against the execution state of the application such that it can be predicated which code pages the application is likely to utilize next. This analysis can be performed on the server, endpoint or any combination of the two. The predicted code pages are proactively pushed and/or pulled such that the application can continue executing without delay. This significantly enhances the performance of application streaming and network file system technologies, and is especially beneficial for very performance sensitive applications.

DETAILED DESCRIPTION

FIG. 1illustrates a system100for proactively transmitting application105content to an endpoint115based on a control flow graph103and current application105execution state, according to some embodiments of the present invention. It is to be understood that although various components are illustrated inFIG. 1as 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 inFIG. 1, a graphing component101produces a control flow graph103for an application105to be streamed. The application can comprise one or more binary images. Where the application105includes dependent executable images or the like (e.g., dynamically linked libraries or other late binding objects), control flow graphs103for these dependent binaries can also be created. The graphing component101can use any methodology for creating the control flow graph(s)103. Various methodologies and tools for creating control flow graphs103of applications105are 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.

A mapping component107maps specific code pages109of the application105to nodes of the control flow graph103. An application developer or the like provides the source code111for the application105being analyzed. The mapping component107, by referring to the corresponding source code111, can map specific code pages109back to specific program functionality, at least roughly, and hence to specific nodes of the graph103some embodiments, some or all of this mapping data112is entered by, for example, an application developer, who has access to both the source code111and the graph103.

It is to be understood that how much of the mapping is performed automatically by the mapping component107, and how much is input by, e.g., an application developer, is a variable design parameter. The implementation mechanics of performing such mapping based on the control flow graph103and the application source code111are within the skill set of one of ordinary skill in the relevant art, and the usage thereof within the context of the present invention will be readily apparent to one of such a skill level in light of this specification.

InFIG. 1, the graphing component101and the mapping component107are illustrated as running on a central server113, which is capable of streaming applications to endpoints115. In other embodiments, these components can run at other locations, as desired.

FIG. 1illustrates a streaming/network file system implementation in which a streaming agent117runs on each target endpoint115and monitors local execution of application105execution.FIG. 1illustrates only a single endpoint115for clarity, but a single server117can and typically does stream application105content to many endpoints115. As illustrated inFIG. 1, in such implementations the control flow graph103and mapping data112are provided to the local streaming agent117on the endpoint115. During the monitoring of the execution of the application105, the streaming agent117analyzes the control flow graph103and mapping data112to determine which code pages109are likely to execute next, based on the application's105current execution state. The streaming agent117pulls the predicted code pages109from the streaming server113before they are needed, such that the application105can continue running without having to throw an exception due to a missing code page109. The streaming agent117can very effectively use the control flow graph103and mapping data112to determine what code pages109should be pulled depending on what branch of code is currently executing, such that the application105always has the necessary code pages109.

FIG. 2illustrates an embodiment of the present invention for use in application streaming/network file system implementations in which there is no streaming agent117running on the endpoint115. Absent the present invention, in such implementations the server113simply pushes the application105to the endpoint115irrespective of the execution context. In the embodiment of the present invention illustrated inFIG. 2, a streaming agent117running on the server113gleans information201concerning the state of application105execution from the communication from the endpoint115. More specifically, the communication protocol used for transmissions between the server113and endpoint115can be adjusted so that communication originating from the endpoint115(e.g., acknowledgements of received packets) includes some type of information201indicative of the execution status of the application105. Based upon the current execution state of the application105, the server113can utilize the control flow graph103and mapping data112to determine which code pages109are likely to execute next. The server113pushes those code pages112to the endpoint115instead of blindly pushing the entire binary and its dependent binaries. The implementation mechanics for modifying communication protocols are known to those of ordinary skill in the relevant art (e.g., modification of a protocol stack, filtering/intercepting relevant system calls, etc.). The usage thereof within the context of the present invention will be readily apparent to one of ordinary skill in the relevant art in light of this specification.

It is to be understood that the analysis concerning which code pages109to push/pull based on the application's105execution state, control flow graph103and mapping data112can also be distributed as desired between the server113and endpoint115. For example, a streaming agent117on the endpoint115could make requests for specific code pages109based on the control flow graph103and mapping data112, and a streaming agent117on the server113could use those requests, the control flow graph103and the mapping data112to predict what code pages109would be requested next. The server113could either send the predicted code pages109to the endpoint115proactively, or load them for sending in anticipation of the predicted requests. This is only one example of distributed predictive analysis. How much of the analysis to instantiate on which computing device is a variable design parameter that can be adjusted as desired.

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.