Currently, many users interact with network-enabled applications. A user on a home computer, for instance, may interact with a web browser application to view web pages over the Internet. Other users may use a remote desktop application to access a remote computer while traveling or tele-commuting.
The current solution of providing desktop/application remoting through the web, as provided by Microsoft, involves loading an ActiveX control within the web browser. Specifically, the Microsoft solution is called the TS Client ActiveX control, and is the same control that powers other network-enabled applications, including Remote Desktop, Remote Web Connection, Remote Programs, Remote Assistance, and Windows Meeting Spaces.
ActiveX controls are Operating System (OS) and architecture dependent components, and are not supported by all web browsers. In addition to these limitations, if the end user does not already have the ActiveX control installed, they would be required to install it before they can use the remote desktop or application. Installation may raise a number of security concerns. Additionally, users would be required to have the permissions or privileges on the machine to actually do the installation. The users may also not understand security implications of installing the component. The control running on their machine may enable access to parts of their system that may be considered secure from the user's perspective.
Techniques disclosed herein address the problem of providing desktop and application remoting by providing a solution with platform independence and no user installation. The web browser is the primary end-user delivery mechanism.
In one implementation, web/web-browser based technology is leveraged to deliver a remoting solution similar to the traditional ActiveX control without requiring users to install any additional components. The user experience would be similar to visiting a conventional web page where the user would see graphics, text, and could fill out and submit forms. From a remote application perspective, the images on a web page appear to be updated as the remote application's “display” changes, and upon receiving input from the web page for the remote application to interact with.
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 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 detailed description is described with reference to the accompanying figures. In the figures, the use of the same reference numbers in different figures indicates similar or identical items.
The following document describes systems and methods that enable a user to access a remote desktop or application using a browser without having to install remote desktop or remote application software or plug-ins. The techniques described herein may provide significant improvements over the current state of the art, potentially providing greater usability of server and server systems, reduced bandwidth costs, and an improved client experience with remote desktops or applications
More specifically, systems and methods (or “tools”) disclosed herein may be capable of providing (1) desktop and application remoting using a web browser as the primary end-user delivery mechanism; (2) an environment that does not require the user to install components; and (3) and platform independence. Exemplary environments in which these tools may enable these and other techniques are described below, followed by other sections describing various inventive techniques and exemplary embodiments of the tools.
Before describing the tools in detail, the following discussion of two exemplary operating environments is provided to assist the reader in understanding two examples of ways in which various inventive aspects of the tools may be employed. The environments described below constitute but two examples and are not intended to limit application of the tools to any particular operating environment. Other environments may be used without departing from the spirit and scope of the claimed subject matter.
The operating environment also includes a network 112 that is connected to the client 102, a web server 120, and a terminal server 130. The network 112 enables communication between the client 102 and the web server 120, and can comprise a global or local network (wired or wireless), such as the Internet or a company's intranet. The network 112 also enables communication between the web server 120 and the terminal server 130.
The web server 120 may include a web server processor(s) 122 and web server computer-readable media 124. The web server processor(s) 122 are capable of accessing and/or executing instructions stored on the web server computer-readable media 124. The web server computer-readable media 124 includes or has access to a web sever module 126 and an embedded terminal server (TS) client 128. The web server 120 in
The terminal server 130 may include a terminal server processor(s) 132 and terminal server computer-readable media 134. The terminal server processor(s) 132 are capable of accessing and/or executing instructions stored on the terminal server computer-readable media 134. The terminal server computer-readable media 134 includes or has access to a terminal sever module 136 and a desktop (or application) 138. The terminal server 130 in
In operation, the input received by client 102 is transmitted to web server 120. The web server 120 then transmits the input to the terminal server 130 using the embedded terminal server client 128. Updated graphics from the desktop or application 138 are sent from the terminal server 130 to the web server 120. The embedded terminal server client 128 and web server module 126 cooperate to serve the updated graphics as an updated web page to the client 102. An advantage of this design is that a web server would be able to connect to multiple terminal servers, however, there would be a larger latency since there is a web server between the client 102 and the terminal server 130 in comparison to traditional Remote Desktop/Terminal Server scenario where the client communicated directly to the terminal server.
Operating environment 200 may include a client 202 having one or more client processor(s) 204 and client computer-readable media 206. The client 202 comprises a computing device, such as a cell phone, desktop computer, personal digital assistant, or server. The processors 204 are capable of accessing and/or executing instructions stored on the computer-readable media 204. The computer-readable media 204 comprises or has access to a browser 208, which is a module, program, or other entity capable of interacting with a network-enabled entity. The browser 208 may be capable of running or responding to one or more scripts 210.
The operating environment 200 also includes a network 212 that is connected to the client 202 and server 220. The network 212 enables communication between the client 202 and the server 220, and can comprise a global or local network (wired or wireless), such as the Internet or a company's intranet.
The server 220 may include a server processor(s) 222 and server computer-readable media 224. The server processor(s) 222 are capable of accessing and/or executing instructions stored on the server computer-readable media 224. The server computer-readable media 224 includes or has access to a web sever module 226, a Remote Desktop or Application Processing (RDP) module 228 and a desktop (or application) 230. Again, the server in
In the embodiment shown in
In this embodiment, the actual remote desktop/application 332 is running on the terminal server 330, therefore the web-server 320 relays the input data to the terminal server 330 using the embedded terminal server (TS) client 322. Thus, the web-server 320 can be considered a translation layer between HTTP and RDP. The web-server 320 would be running an implementation of an embedded TS client 322 in order to communicate to the terminal server 330 through RDP.
In the embodiment shown in
In the embodiment shown in
In this embodiment, the actual remote desktop/application 426 is running on the same server 420 as the web-server 422. The web-server 422 relays the input data to the input driver in the RDP display and an input driver 424 associated with the user's session. The RDP display and input driver 424 will then send the input into the user's session in the desktop or application 426.
Graphics data originates at the server 420 running the web server 422 since it is the same server running the remote desktop/applications 426. When the desktop/application 426 changes, the web-server 422 may be notified of the change or update. At this point, the web server 422 may request the RDP display and input driver 424 for the updated graphics data. The web-server 422, after receiving the updated graphics data, converts the graphics data into a standard image format that a web-browser could render (e.g., jpeg, gif, png). The graphics data would then be sent to the web-browser 410, and the web-browser 410 uses the image to update its graphics representation of the desktop/application 426. In other embodiments, the desktop or application 426 could send the updated graphics data to the RDP display and input driver 424. The RDP display and input driver 424 could then forward this graphics data to the web-server 422.
Generally speaking, in order to maintain an accurate graphical representation of a remote desktop or application, a web page operating in accordance the teachings of the present disclosure receives images from a web-server through HTTP, and then dynamically updates the portion of its representation that has changed. This can be done by using Asynchronous JavaScript and XML (AJAX) or other similar technology.
For example,
By using techniques in accordance with the present disclosure, the web-page could make this request, get the new image data, and update the web-browser, without refreshing (e.g. reloading) the page.
Two examples of mechanisms or processes that a browser may use to get the graphics data in accordance with the teachings of the present disclosure are shown in
In this embodiment, the server could send the updated graphics data to the browser as a list of image URLs, along with positioning information for each image, in block 608. After the web browser receives the updated graphic data in block 610, a script running in the web browser creates new ‘image objects’, positions them correctly, and points their URL to a list of file names received in block 612. The web-browser then goes back to the web-server and fetches the images in block 614.
Similarly, in the example shown in
In this embodiment, the server could respond by sending position information for a set of images, and the images themselves as binary data in block 708. In one embodiment the binary data is sent using Base64 encoding. After the web browser receives the updated graphic data in block 710, a script running in the web browser creates new ‘image objects’, positions them correctly, and sets the image's contents to the binary data received from the server in block 712.
Two possible methods of sizing image updates may be used: uniform tiles and non-uniform tiles. When using uniform tiles, the desktop/application is divided into a uniform grid of tiles. Each tile may have an index and be represented by an HTML DIV tag on the web page. In this scenario, DIVs can be thought of as positionable components within a web-page. The DIV would contain an image of the tile. When the web-server sends image data to the web-browser, script running on the web browser places the image in the proper DIV based on the index of the tile that it is updating.
When using non-uniform tiles, the web-server may send the web-browser non-uniform sized images along with their size and position in coordinates. The web page creates a DIV for the new image, and then sizes and positions it according to the data provided by the server. When a DIV is no longer visible, it typically is removed from the web page.
When an updated portion of a desktop/application is received, it typically replaces some existing portion of the desktop/application. In certain situations, this may cause a slight flicker because within a DIV the ‘image object’ is replaced by a new ‘image object’. When this happens there may be a moment where there is no image displayed at all. Double buffering may be used to fix this problem.
While the new image is loading, the other DIV will either be behind the new DIV, or on top of it (depending on how the browser handles updating the image and the DIV's z-order). If the new image is temporarily blank, you will either see through it if the other DIV is behind it, or be blocked by the other DIV if it's in front. Since you will always see an image, you will never see a flash of a missing image when a tile is being updated.
When viewing a remote desktop/application there may be a number of images that are consistently repeated. For example, in Windows, the desktop background or Start Menu may change visibility a number of times during a session as the user interacts with the desktop. Client side caching in the web-browser would help improve the responsiveness of the changes in the desktop by caching frequently viewed components.
If the server recognizes that the tile or image is cached by the web-browser in block 1004, instead of sending the tile or image, the server will tell the web browser to use its cached copy of the tile or image using the image identifier in block 1006. When the image or tile is not stored in the web browser cache and the server recognizes that the same image has been sent to the web-browser in the past in block 1008, the server may tell the web-browser to cache the image and provides an identifier to identify the cached item in block 1010. In some embodiments, the identifier may be a unique identifier. In other embodiments, the identifier may be unique to the user or to the particular user's session. Thereafter, the image or tile is sent by the server in block 1012.
By using techniques in accordance with the present disclosure, a web-page can allow a user to provide input to a remote application. The web-page would wait for input events from the user (such as keystrokes and mouse events) and would make an HTTP request through the XMLHTTP object to the web-server, notifying it of the input events that have just occurred.
A simple approach for sending input from the web-browser to the web-server would be to listen for key stroke and mouse events, and make an HTTP request to the server through the XMLHTTP object for each input event. Since input typically occurs very frequently (imagine how many events are generated when the user just moves the mouse), making a separate request for each input event would be very inefficient.
Instead of making a single request for each event, input batching may be used.
This mechanism maximizes the use of the HTTP connection by sending as much data as possible at the time of the connection. Depending on the limitation of number of XMLHTTP objects that are available, it is good practice to use a separate XMLHTTP objects for receiving graphics and sending input. This allows graphics and input to be sent and received in parallel. Input data may be accumulated in a list or array type data structure in the web-browser.
In some embodiments, when XMLHTTP object finishes transmitting data, it checks this data structure and issues a new request or reissues the request if there is data available in the data structure. When an HTTP request is issued to the web-server, the input events are encoded in the URL. The input events may be differentiated from one another by tagging a unique ID at the end of their parameter names. The IDs are used to differentiate one input event from another in a batch, and to provide ordering information to maintain the order of the events as generated by the user.
The following is an example of an event URL:
In this case, the user must have pressed the key with the keyCode 200, and followed by releasing it. The web-server will look at the eventType field and determine that the request is for input. It will then look at the ioCount, and query all ioType's from 0 to (ioCount−1) to find each input event.
The above-described systems and methods enable a user to access a remote desktop or application using a browser without having to install remote desktop or remote application software or plug-ins. These and other techniques described herein may provide significant improvements over the current state of the art, potentially providing greater usability of server and server systems, reduced bandwidth costs, and an improved client experience with remote desktops or applications. Although the systems and methods have been described in language specific to structural features and/or methodological acts, it is to be understood that the systems and methods 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 systems and methods.