Patent Application
20220353335
Remote desktop technologies allow a user that is physically interacting with a local computer to control and view a remote desktop session originating from a remotely located computer. The local computer is commonly referred to as a remote desktop client computer, or simply a “client computer,” while the remote computer is commonly referred to as a remote desktop session host.
A remote desktop client application running on a client computer and a remote desktop server application running on a remote desktop session host together facilitate “remoting” a desktop session. The remote desktop client application receives user input, such as keyboard or mouse input, and converts the input into a network-compatible representation to be transmitted to the remote desktop server application.
The remote desktop server application running on the remote desktop session host receives the network-compatible representation of the user input and converts this representation into input messages. The remote desktop session host processes the input messages as if they were generated locally. Therefore, applications running on the remote desktop session host respond to input made at the client computer as if the input was generated locally to the remote desktop session host.
In addition, applications and the operating system running on the remote desktop session host periodically generate graphics output. In a remote desktop infrastructure environment, the graphics output of a remote desktop session host is typically not displayed on a monitor or other viewing device attached to the host. Instead, the remote desktop server application converts the graphics output to a network-compatible representation and transmits the representation to the client computer. The network-compatible representation is received by the remote desktop client application and dis- played on a display device attached to the client computer. Using this mechanism, a user can utilize a client computer to interact with and utilize the operating system and applications executing on a remote desktop session host as if they were physically co-located.
In many remote desktop infrastructure environments, networking devices implementing the network address translation (“NAT”) protocol (and potentially other security protocols, firewalls, etc.) may be utilized on the private networks upon which remote desktop client computers reside. Similarly, NAT devices and other network security devices might also be implemented on the private networks hosting remote desktop session hosts. These devices provide improved network security to devices located on the respective private networks but, at the same time, can make establishing network sessions between remote desktop clients and remote desktop session hosts on different private networks difficult.
To overcome this challenge, remote desktop sessions have traditionally been established using the WebSocket protocol over a Transmission Control Protocol (“TCP”) connection using a gateway. For instance, a remote desktop client computer might establish a WebSocket TCP connection to a gateway located within the private network of a remote desktop session host. The remote desktop session host might also, in turn, establish a Web Socket TCP connection to the same gateway to enable communication with the remote desktop client computer therethrough.
The solution described above for session establishment in remote desktop infrastructure environments has several technical disadvantages. In particular, the WebSocket protocol is not ideal for long-lived network connections such as remote desktop sessions. As a result, remote desktop clients and remote desktop session hosts can be frequently disconnected from one another. This can be frustrating for users, reduce productivity, and unnecessarily utilize computing resources to reestablish remote desktop sessions. Additionally, the TCP protocol is not ideal for use with remote desktop connections, particularly on noisy networks. For instance, the TCP protocol can be aggressive in how it handles retransmission on noisy networks, which can significantly impact the performance of remote desktop sessions.
It is with respect to these and other technical challenges that the disclosure made herein is presented.
Technologies are disclosed for performing session establishment in remote desktop infrastructure environments. Through implementations of the disclosed technologies, remote desktop networking sessions can be securely established between remote desktop client computers and remote desktop session hosts in environments where NAT devices are present and in a manner that does not utilize the Web Socket protocol or the TCP protocol. As a result, secure remote desktop sessions can be established and maintained that are more performant and that do not disconnect as frequently as when previously solutions are utilized. Other technical benefits not specifically mentioned herein can also be realized through implementations of the disclosed subject matter.
In order to realize the technical benefits mentioned briefly above, a remote desktop client application obtains client candidate network addresses using the Interactivity Connectivity Establishment (“ICE”) protocol and provides the client candidate network addresses to an instance of a remote desktop server application. The client candidate network addresses can include host candidates, reflexive candidates, and relayed candidates. The client candidate network addresses might be referred to herein as “client candidate addresses” or “client candidates.”
The instance of the remote desktop server application obtains server candidate network addresses also using the ICE protocol and provides the server candidate network addresses to the remote desktop client application. The server candidate network addresses can also include host candidates, reflexive candidates, and relayed candidates. The server candidate network addresses might be referred to herein as “server candidate addresses” or “server candidates.”
The remote desktop client application and remote desktop server application evaluate the client network addresses using the ICE protocol to select a pair of network addresses for establishing a communication session. The remote desktop client application and remote desktop server application establish a remote desktop protocol over User Datagram Protocol (“UDP”) network session using the selected network addresses. The network session, or connection, might be established using local network addresses, might be relayed, such as through a media relay service implementing the Traversal Using Relays around NAT (“TURN”) protocol), or using translated transport addresses on the public side of a NAT device, or devices. The remote desktop client application and remote desktop server application can then transmit remote desktop protocol data over the established network connection.
As discussed briefly above, implementations of the technologies disclosed herein can enable establishment of remote desktop sessions between remote desktop client computers and remote desktop session hosts even when NAT devices are present and remote desktop sessions that are more performant and that do not disconnect as frequently as compared to when previous solutions are utilized. Other technical benefits not specifically identified herein can also be realized through implementations of the disclosed technologies.
It should be appreciated that the above-described subject matter can be implemented as a computer-controlled apparatus, a computer-implemented method, a computing device, or as an article of manufacture such as a computer readable medium. These and various other features will be apparent from a reading of the following Detailed Description and a review of the associated drawings.
This Summary is provided to introduce a brief description of some aspects of the disclosed technologies 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 that this Summary be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
The following detailed description is directed to technologies for session establishment and communication in remote desktop infrastructure environments. As discussed briefly above, implementations of the technologies disclosed herein can enable secure establishment of remote desktop networking sessions between remote desktop client computers and remote desktop session hosts that are behind NAT devices and remote desktop sessions that are more performant and that do not disconnect as frequently as compared to previous solutions. Other technical benefits not specifically mentioned herein can also be realized through implementations of the disclosed subject matter.
While the subject matter described herein is presented in the general context of connection establishment and maintenance between remote desktop client computers and remote desktop session hosts, those skilled in the art will recognize that other implementations can be performed in combination with other types of computing systems and modules. Those skilled in the art will also appreciate that the subject matter described herein can be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, computing or processing systems embedded in devices (such as wearable computing devices, automobiles, home automation etc.), mini-computers, mainframe computers, and the like.
In the following detailed description, references are made to the accompanying drawings that form a part hereof, and which are shown by way of illustration specific configurations or examples. Referring now to the drawings, in which like numerals represent like elements throughout the several FIGS., aspects of various technologies for performing session establishment in remote desktop infrastructure environments will be described.
The applications 106 and 108 together facilitate “remoting” a desktop session. In particular, the remote desktop client application 106 receives user input 110 from a user, such as keyboard or mouse input, and converts the user input 110 into a network-compatible representation to be transmitted to the remote desktop session host 104. The remote desktop server application 108 running on the remote desktop session host 104, in turn, receives the network-compatible representation of the user input 110 and converts this representation into input messages. The remote desktop session host 104 processes the input messages as if they were generated locally thereto. Therefore, applications and the operating system running on the remote desktop session host 104 respond to user input 110 made at the remote desktop client computer 102 as if the input was generated by a user physically proximate to the remote desktop session host 104.
In addition, applications and an operating system (not shown in FIG.1) executing on the remote desktop session host 104, periodically generate graphics output. In the remote desktop infrastructure environment 100, the graphics output of a remote desktop session host 104 is typically not displayed on a monitor or other viewing device attached to the host 104. Instead, the remote desktop server application 108 converts the graphics output to a network-compatible representation and transmits the representation to the remote desktop client computer 102.
The network-compatible representation of the graphics output is received by the remote desktop client application 106 and presented by way of a user interface 112 on a display device (not shown in
As shown in
The private network 114 and the distributed computing network 118 can be connected via one or more public networks 116, such as the Internet. The remote desktop client computer 102 is commonly implemented as a desktop or laptop computing device while the remote desktop session host 104 might be implemented as a physical server computer or a virtual machine. Other implementations can also be utilized. In this regard, it is to be appreciated that the networking topology shown in
As discussed briefly above, networking devices implementing the NAT protocol in the private network 114 and the distributed computing network 118 provide improved security to devices located within these networks but, at the same time, can make establishing network sessions between remote desktop client computers 102 and remote desktop sessions hosts 104 in these networks difficult. To overcome this technical limitation, remote desktop sessions have traditionally been established using the Web Socket protocol over transmission control protocol (“TCP”) using a gateway (not shown in
For instance, a remote desktop client computer 102 might establish a WebSocket TCP connection to a gateway within the private network (e.g., the distributed computing network 118) of a remote desktop session host 104. The remote desktop session host 104 might also, in turn, establish a Web Socket TCP connection to the same gateway to enable communication with the remote desktop client computer 102 therethrough. Remote desktop protocol data can then be exchanged between the remote desktop client computer 102 and the remote desktop session host 104 by way of the gateway.
As mentioned previously, the solution described above for session establishment in remote desktop infrastructure environments has several technical disadvantages. In particular, the Web Socket protocol is not ideal for long-lived network connections such as remote desktop sessions. As a result, remote desktop client computers 102 and remote desktop session hosts 104 can be frequently disconnected from one another. This can be frustrating for users, reduce productivity, and unnecessarily utilize computing resources to reestablish remote desktop sessions. Additionally, the TCP protocol is not ideal for use with remote desktop connections, particularly on noisy networks. For instance, the TCP protocol can be aggressive in how it handles retransmission on noisy networks, which can significantly impact the performance of remote desktop sessions. It is with respect to these and other technical challenges that the disclosure made herein is presented.
In order to address the technical challenges set forth above, and potentially others, technologies are disclosed herein for secure and performant network session establishment in a remote desktop infrastructure environment 100. In particular, according to various embodiments disclosed herein, the remote desktop client application 106 and the remote desktop server application 108 are configured to implement the Interactivity Connectivity Establishment (“ICE”) protocol 120 to select network addresses 122 (i.e., one for the remote desktop client application 106 and one for the remote desktop server application 108) for use establishing a network connection 124A or 124B for use in communicating with one another. Once a connection 124A or 124B has been established, remote desktop protocol data can be transmitted between the remote desktop client application 106 and the remote desktop server application 108 using User Datagram Protocol (“UDP”) datagrams, thereby avoiding the shortcomings associated with TCP.
As will be described in greater detail below, the disclosed implementations of the ICE protocol 120 can traverse NAT devices and firewalls, such as those present in the private network 114 and the distributed computing network 118, and establish an efficient network path in terms of media latency to ensure ideal media quality. Details regarding the ICE protocol 120 can be found in the publicly available RFC 5245, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols, J. Rosenberg (Apr. 2010). Certain extensions to the ICE protocol are defined in [MS-ICE2] Interactive
Connectivity Establishment (ICE) Extensions documentation (http://msdn.microsoft.com/en-us/library/office/cc431504(v=office.12). aspx).
In the context of the ICE protocol 120, a direct network path (i.e., a path not involving the use of a media relay service 126, such as a service implementing the Traversal Using Relays around NAT (“TURN”) protocol) between endpoints is preferred for a media session over an indirect path (i.e., a path that involves using a media relay service 126). A network path is identified by a pair of network addresses 122, one of which is used to transmit and receive data by an initiating endpoint (e.g., a remote desktop client computer 102) and the other to transmit and receive data by a responding endpoint (e.g., a remote desktop session host 104).
As will be described in greater detail below, the ICE protocol 120 attempts to identify what it deems to be the most efficient path based on static priorities, which are assigned to each of several “candidate pairs” of network addresses that could be used to establish a networking session. A candidate is a network address associated either an initiating endpoint (e.g., a remote desktop client computer 102) or a responding endpoint (e.g., a remote desktop session host 104). A candidate pair is a pair of network addresses, the first network address associated with the initiating endpoint and the second with the responding endpoint.
The term “candidate” relates to the fact that the mechanism implemented by the ICE protocol 120 initially assumes that any transport address associated with an endpoint might be useable for a media session, though it might not actually be useable for various reasons, some of which are described below. The ICE protocol 120 then involves detecting which of the identified candidates are useable and selecting a pair of network addresses 122 from among the candidates for use. Additional details regarding this process will be provided below.
The ICE protocol 120 classifies candidates into three categories: host candidates; reflexive candidates; and relayed candidates. A host candidate is a network address which is local to the endpoint in question (i.e., on a network interface directly attached to the endpoint). For example, the network address of the remote desktop client computer 102 on the private network 114 is local to that device and is therefore a host candidate. Similarly, if the remote desktop client computer 102 were to be directly connected to the public network 116, it would have its own public address on the public network 116, which would also be a host network address. In a similar fashion, the remote desktop session host 104 also has its own local address, or addresses, which are also host candidates.
A reflexive candidate is a network address that is not local to an endpoint, but which is a translated network address on the public side of a NAT device. These are classed into two subcategories: “server reflexive candidates,” which are public NAT addresses discovered by querying a server (e.g., a server implementing the Session Traversal Utilities for NAT (“STUN”) protocol described below), and “peer reflexive candidates,” which are discovered by the other endpoint during the establishment of the media session (e.g., a public side NAT address associated with the initiating endpoint as discovered by the responding endpoint, or vice versa). A relayed candidate is a network address allocated from a media relay service 126, such as a media relay service implementing the TURN protocol.
Additional details regarding the STUN protocol and the TURN protocol, described briefly above, will now be provided. The STUN protocol allows an endpoint to determine whether it is located behind a device implementing the NAT protocol and, if so, to also discover the public address of the NAT device that is mapped to the private address of the initiating endpoint. This effectively gives the endpoint access to the mapping implemented by the NAT so that the endpoint may include the public address in the payload(s) it transmits rather than its own private network address. For example, the remote desktop client application 106 might utilize the STUN protocol to determine the public network address mapped to its network address by a NAT device in the private network 114.
Typically, the STUN protocol works by the initiating endpoint, such as the remote desktop client application 106, sending a query to a STUN server, which is relayed to the STUN server through the NAT device and via the public network as IP datagrams. Because the NAT device replaces the private address in the IP header of the query with the corresponding public address on the public side of the NAT device, the STUN server can obtain the latter from the IP headers of the query, which it can, in turn, provide to the initiating endpoint. The initiating endpoint can then establish a session using that public address rather than its own private address, thereby conveying a useable address at the IP payload level to the responding endpoint in the session request.
A responding endpoint, such as the remote desktop server application 108, can similarly discover its associated public address, which it can convey to the initiating endpoint at the application data level in the response rather than its own private address. The role of a STUN server is effectively one of providing address discovery, and generally it does not participate in a media session once established.
It is to be appreciated that there are circumstances in which a network session cannot be established between endpoints even when the public address of a NAT device is known, for instance when the initiating and/or responding endpoint is behind a symmetric NAT device. In such circumstances, one or more services or servers implementing the TURN protocol can often be used to traverse the NAT by relaying media data, such as remote desktop protocol data. In the embodiment shown in
When an endpoint needs to use a TURN relay, such as the media relay service 126, it sends a request requesting that a unique public transport address (i.e., an individual port, provided by the media relay service 126) be allocated to the endpoint. If the request is accepted, the media session is then established using that public address of the media relay service 126 as the source address for that endpoint. That endpoint sends to the media relay service 126 media (e.g., remote desktop protocol data) that it wishes to transmit in the session contained in TURN messages.
The media relay service 126 extracts the media from the TURN messages, and relays it onwards from the public address provided by the media relay service 126 that has been allocated to that endpoint as a source address. The media relay service 126 also relays data intended for that endpoint that has been directed to the address allocated on the media relay service 126 to that endpoint contained in TURN messages for extraction by that endpoint.
If both endpoints are located behind NATs that do not permit STUN, then each will need its own respective transport address to be allocated on the media relay service 126, in which case the media session is established between those two allocated TURN server addresses and each endpoint relays/receives data in TURN messages, with data provided to the media relay service 126 being transmitted and received to/from the two TURN server addresses allocated to those endpoints in the media session.
TURN relaying in the manner described above requires resources, including the unique public transport address, or addresses, allocated on the media relay service 126 to be allocated on that server for at least the duration of that media session, and means that media of the media session travels via a less direct path than when a media session is established directly between the endpoints or via one or more NATs. Though it does require additional resources, TURN relaying in the manner described above can more or less guarantee to provide a useable path through a network for a media session. Additional details regarding these processes can be found in the publicly available RFC 5766: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN).
It is to be appreciated that both STUN and TURN functionality can be incorporated in the same server, or service, which is sometimes also referred simply to as a TURN/STUN server or service or simply as a TURN server or service even though it also includes STUN functionality. The media relay service 126 shown in
As will be described in greater detail below, the remote desktop client application 106 and the remote desktop server application 108 both utilize the ICE protocol 120 to identify candidate network addresses for use in establishing a networking session. Potentially, any of the candidate network addresses identified by the remote desktop client application 120 can be used to communicate with any of the candidate network addresses identified by the remote desktop server application 108. That is, the remote desktop client application 120 can potentially direct data from any of its own associated candidate network addresses to any of the candidate network addresses associated with the remote desktop server application 108 and vice versa.
In practice, however, some candidate pairs of network addresses will not be valid (i.e., will not work). For instance, if the endpoints are both behind NATs and their host candidates network addresses are private addresses in private networks, they are unlikely to be able to communicate directly using those addresses. However, if their host candidates are public addresses which, when used, do not involve routing data through any NAT devices, then the candidate pair may well be valid. Similarly, depending on the type of NAT devices (e.g., symmetric NAT devices), use of reflexive candidate network addresses may not be possible. Each candidate pair thus potentially represents a path through the network of a certain type, although such a path will only be available in practice if the candidate pair is valid.
As discussed briefly above, the ICE protocol 120 attempts to identify what it deems to be the most efficient path between endpoints based on static priorities, which are assigned to the candidate pairs described above. The order in which candidate pairs are tried is dictated by a static priority scheme defined by the ICE protocol 120, with higher priority pairs being tried ahead of lower priority pairs. The ICE protocol 120 then determines which network address is best for both endpoints to use to establish a media session.
In the second scenario illustrated in
In both scenarios shown in
It is to be appreciated that the embodiments disclosed herein can be utilized with various types of remote desktop protocols. For example, and without limitation, the embodiments disclosed herein can be utilized with the Apple Remote
Desktop Protocol (“ARD”) from APPLE, INC., the Appliance Link Protocol (“ALP”), the HP Remote Graphics Software (“RGS”) protocol from HEWLETT PACKARD, the PC-over-IP (“PcoOP”) protocol utilized by VMWARE, the Remote Desktop Protocol (“RDP”) from MICROSOFT CORPORATION, the Remote Frame Buffer Protocol (“RFB”) utilized by VNC, the X Window System, and others. The disclosure presented herein is not limited to a particular remote desktop protocol. Additional details regarding the various embodiments disclosed herein for establishing networking sessions in remote desktop infrastructure environments will be provided below with regard to
One of the network services 128 is the media relay service 126 described above. As mentioned above, the media relay service 126 provides STUN functionality, which allows an endpoint to determine whether it is located behind a device implementing the NAT protocol and, if so, the public address of the NAT device that is mapped to the private address of the initiating endpoint. For example, the remote desktop client application 106 might utilize the STUN protocol provided by the media relay service 126 to determine the public network address mapped to its network address by a NAT device in the private network 114. The remote desktop server application 108 can utilize the STUN functionality provided by the media relay service 126 in a similar fashion.
As also mentioned above, the media relay service 126 also provides TURN functionality. As discussed above, if both network endpoints are located behind NATs that do not permit STUN, then each will need its own respective transport address to be allocated on the media relay service 126, in which case the media session is established between those two allocated TURN server addresses and each endpoint relays/receives data in TURN messages, with data provided to the media relay service 126 being transmitted and received to/from the two TURN server addresses allocated to those endpoints in the media session. Additional details regarding this process are provided below.
As illustrated in
As will be described in greater detail below, the remote desktop gateway service 202 is a front-end service which, among other things, provides functionality to instances of the remote desktop client application 106 for determining if an instance of the media relay service 126 is available for use. Additional details regarding this process will be provided below.
The remote desktop broker service 204 provides functionality for authentication and authorization, tracking the status of remote desktop session hosts 104, tracking the applications published by remote desktop session hosts 104, selection of a particular remote desktop session host 104 for a particular user, and other types of functionality, some of which will be described in greater detail below.
The media relay management service 206 provides functionality for discovering and selecting from available instances of the media relay service 126, authentication, and other functionality described below. In this regard, it is to be appreciated that the network services 128 shown in
As shown in
In the illustrated environment, the process of initiating a remote desktop session between an instance of the remote desktop client application 106 and an instance of the remote desktop server application 108 executing on a remote desktop session host 104 begins at operation 250, when a user selects a user interface (“UI”) element in the user interface 112 for initiating a connection. A connection can be initiated in other ways in other configurations.
In response to a user initiating a connection request, the remote desktop client application 106 transmits a request for the identity of one or more servers, or services, implementing aspects of the ICE protocol (e.g., the STUN and TURN functionality implemented by media relay service 126) to the remote desktop gateway service 202 at operation 252. In response thereto, the remote desktop gateway service 202 attempts to obtain a token for an instance of the media relay service 126 from the media relay management service 206. The token, which might also be referred to as a “TURN token” provides the network address of an instance of the media relay service 126 and a credential that can be utilized to access the instance of the media relay service 126.
If an instance of the media relay service 126 is available, the media relay management service 206 returns the TURN token to the remote desktop gateway service at operation 256. The TURN token is provided to the requesting instance of the remote desktop client application 106, in turn, at operation 258. As will be described in greater detail below, the instance of the remote desktop client application 106 can utilize the token to obtain its candidate network addresses.
It is to be appreciated that in some scenarios it might not be possible for the remote desktop gateway service 202 to obtain a token for an instance of the media relay service 126. In these instances, the remote desktop gateway service 202 can provide an instruction to the instance of the remote desktop client application 106 to establish a connection to the remote desktop server application 108 using the Web-Socket protocol over a TCP connection using the gateway. For instance, the remote desktop client application 106 might establish a Web Socket TCP connection to the remote desktop gateway service 202. The remote desktop session host 104 might also, in turn, establish a WebSocket TCP connection to the remote desktop gateway service 202 to enable communication with the remote desktop client application 106 therethrough. Other types of fallback mechanisms might be alternately utilized when a server or service supporting the ICE protocol 120 are not available for use in establishing a remote desktop session.
If the remote desktop client application 106 can obtain a TURN token, the remote desktop client application 106 can utilize the TURN token to access the media relay service 126 and obtain candidate network addresses at operation 260. As discussed above, the candidate addresses for the remote desktop client application 106 can include host candidates (i.e., addresses local to the endpoint), reflexive candidates (translated transport addresses on the public side of a NAT device obtained using the STUN protocol), and relayed candidates (network addresses allocated from a media relay service 126 implementing the TURN protocol, for instance).
Once the remote desktop client application 106 has obtained its candidate network addresses (which might be rereferred to as “client candidate addresses”), it passes the client candidate addresses 262 to the remote desktop gateway service 202 at operation 262. In turn, the remote desktop gateway service 202 obtains a TURN token from the media relay management service 206 for use by the remote desktop server application 108 at operations 264 and 266. The remote desktop gateway service 202 then passes the TURN token to the remote desktop agent 210 and, in turn, to the appropriate instance of the remote desktop server application 108 at operation 268. The remote desktop gateway service 202 also provides the client candidate addresses obtained in the manner described above to the remote desktop server application 108 at operation 268.
At operation 270, the remote desktop server application 108 utilizes the TURN token to obtain its candidate network addresses (which might be referred to herein as “server candidate addresses”). As in the case of the remote desktop client application 106, the candidate addresses for the remote desktop server application 108 can include host candidates (i.e., addresses local to the endpoint), reflexive candidates (translated transport addresses on the public side of a NAT device obtained using the STUN protocol), and relayed candidates (network addresses allocated from a media relay service 126 implementing the TURN protocol, for instance).
The illustrated process for establishing a remote desktop session between a remote desktop client computer 102 and a remote desktop session host 104 continues in
At operations 274 and 276, the remote desktop client application 106 and the remote desktop server application 108, respectively, evaluate the client candidate addresses and the server candidate addresses according to the ICE protocol. In particular, candidate addresses are evaluated by performing connectivity checks on candidate pairs of client and server network addresses.
Following the connectivity checks, the remote desktop client application 106 can nominate a pair of network addresses 122 and provide the nominated network addresses 122 to the remote desktop server application 108 for use in connection establishment. In this regard, it is to be appreciated that that the process for obtaining client and server candidates and for evaluating candidates has been simplified herein for ease of discussion. As discussed above, additional details regarding these processes can be found in the publicly available RFC 5245, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols, J. Rosenberg (Apr. 2010).
After a pair of network addresses 122 have been selected for the remote desktop session between the remote desktop client application 106 and the remote desktop server application 108, a connection between the two applications can be established. In this regard,
In the first scenario shown in
In the second scenario illustrated in
In both scenarios shown in
The process for establishing a second or subsequent remote desktop protocol transport channel between the remote desktop client computer 102 and the remote desktop session host 104 begins at operation 278, where the remote desktop server application 108 collects its server candidate addresses using the ICE protocol in the same way as described above with regard to
Once the remote desktop server application 108 has collected it server candidate addresses, it transmits the server candidate addresses to the remote desktop client application 106 at operation 280. Since a network connection 124A or 124B has been previously established, this network connection can be utilized to transmit the server candidate addresses to the remote desktop client application 106. This avoids the service setup process described above with regard to
At operation 282, the remote desktop client application 106 collects the client candidate addresses using the ICE protocol in the manner described above with regard to
After a pair of network addresses 122 have been selected for the second or subsequent transport channel between the remote desktop client application 106 and the remote desktop server application 108, the second or subsequent remote desktop protocol transport channel between the two applications can be established. In this regard,
In the first scenario shown in
The particular implementation of the technologies disclosed herein is a matter of choice dependent on the performance and other requirements of the computing device. Accordingly, the logical operations described herein are referred to variously as states, operations, structural devices, acts, or modules. These states, operations, structural devices, acts and modules can be implemented in hardware, software, firmware, in special-purpose digital logic, and any combination thereof. It should be appreciated that more or fewer operations can be performed than shown in the FIGS. and described herein. These operations can also be performed in a different order than those described herein.
The routine 300 begins at operation 302, where the remote desktop client application 106 determines whether the ICE protocol 120 is available and should be utilized. As discussed above with regard to
If, at operation 304, it is determined that a TURN token cannot be obtained, the routine 300 proceeds from operation 304 to operation 316, where a fallback procedure might be utilized in order to establish a connection between the remote desktop client application 106 and the remote desktop server application 108. In particular, and as discussed briefly above, the remote desktop gateway service 202 might provide an instruction to the instance of the remote desktop client application 106 to establish a connection to the remote desktop server application 108 using the Web Socket protocol over a TCP connection using a gateway.
For instance, the remote desktop client application 106 might establish a WebSocket TCP connection to the remote desktop gateway service 202. The remote desktop session host 104 might also, in turn, establish a Web Socket TCP connection to the remote desktop gateway service 202 to enable communication with the remote desktop client application 106 therethrough. Other types of fallback mechanisms might be alternately be utilized when a server or service supporting aspects of the ICE protocol 120 are not available for use in establishing a remote desktop session. The routine 300 proceeds from operation 316, to operation 318, where it ends.
If the ICE protocol 120 is to be utilized, the routine 300 proceeds from operation 304 to operation 306. At operation 306, the remote desktop client application 106 utilizes an implementation of the ICE protocol 120 to obtain the client candidate network addresses in the manner described above with regard to
From operation 306, the routine 300 proceeds to operation 308, where the remote desktop server application 108 utilizes an implementation of the ICE protocol 120 to obtain the server candidate addresses in the manner described above with regard to
At operation 309, the remote desktop server application 108 and the remote desktop client application 106 evaluate the client and server candidate addresses using the ICE protocol and select network addresses 122 for the remote desktop session in the manner described above with regard to
From operation 310, the routine 300 proceeds to operation 312, where a determination is made as to whether additional remote desktop protocol transport channels are to be established between the remote desktop server application 108 and the remote desktop client application 106. If so, the routine 300 proceeds from operation 312 to operation 314, where the ICE protocol 120 can be utilized to establish additional communication channels between the remote desktop server application 108 and the remote desktop client application 106 in the manner disclosed above with regard to
The computer 400 illustrated in
The mass storage device 412 is connected to the CPU 402 through a mass storage controller (not shown) connected to the bus 410. The mass storage device 412 and its associated computer readable media provide non-volatile storage for the computer 400. Although the description of computer readable media contained herein refers to a mass storage device, such as a hard disk, CD-ROM drive, DVD-ROM drive, or USB storage key, it should be appreciated by those skilled in the art that computer readable media can be any available computer storage media or communication media that can be accessed by the computer 400.
Communication media includes computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics changed or set in a manner so as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.
By way of example, and not limitation, computer storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. For example, computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid-state memory technology, CD-ROM, digital versatile disks (“DVD”), HD-DVD, BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and which can be accessed by the computer 400. For purposes of the claims, the phrase “computer storage medium,” and variations thereof, does not include waves or signals per se or communication media.
According to various configurations, the computer 400 can operate in a networked environment using logical connections to remote computers through a network such as the network 420. The computer 400 can connect to the network 420 through a network interface unit 416 connected to the bus 410. It should be appreciated that the network interface unit 416 can also be utilized to connect to other types of networks and remote computer systems such as those shown in
It should be appreciated that the software components described herein, when loaded into the CPU 402 and executed, can transform the CPU 402 and the overall computer 400 from a general-purpose computing device into a special-purpose computing device customized to facilitate the functionality presented herein. The CPU 402 can be constructed from any number of transistors or other discrete circuit elements, which can individually or collectively assume any number of states. More specifically, the CPU 402 can operate as a finite-state machine, in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions can transform the CPU 402 by specifying how the CPU 402 transitions between states, thereby transforming the transistors or other discrete hardware elements constituting the CPU 402.
Encoding the software modules presented herein can also transform the physical structure of the computer readable media presented herein. The specific transformation of physical structure depends on various factors, in different implementations of this description. Examples of such factors include, but are not limited to, the technology used to implement the computer readable media, whether the computer readable media is characterized as primary or secondary storage, and the like. For example, if the computer readable media is implemented as semiconductor-based memory, the software disclosed herein can be encoded on the computer readable media by transforming the physical state of the semiconductor memory. For instance, the software can transform the state of transistors, capacitors, or other discrete circuit elements constituting the semiconductor memory. The software can also transform the physical state of such components in order to store data thereupon.
As another example, the computer readable media disclosed herein can be implemented using magnetic or optical technology. In such implementations, the software presented herein can transform the physical state of magnetic or optical media, when the software is encoded therein. These transformations can include altering the magnetic characteristics of particular locations within given magnetic media. These transformations can also include altering the physical features or characteristics of particular locations within given optical media, to change the optical characteristics of those locations. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this discussion.
In light of the above, it should be appreciated that many types of physical transformations take place in the computer 400 in order to store and execute the software components presented herein. It also should be appreciated that the architecture shown in
In a network environment in which the communications network 420 is the Internet, for example, the server computer 500A can be a dedicated server computer operable to process and communicate data to and from the client computing devices 500B-500G via any of a number of known protocols, such as, hypertext transfer protocol (“HTTP”), file transfer protocol (“FTP”), a remote desktop protocol, TCP, UDP, or simple object access protocol (“SOAP”). Additionally, the networked computing environment 500 can utilize various data security protocols such as secured socket layer (“SSL”) or pretty good privacy (“PGP”). Each of the client computing devices 500B-500G can be equipped with an operating system operable to support one or more computing applications or terminal sessions such as a web browser (not shown in
The server computer 500A can be communicatively coupled to other computing environments (not shown in
The data and/or computing applications may be stored on the server 500A, or servers 500A, and communicated to cooperating users through the client computing devices 500B-500G over an exemplary communications network 420. A participating user (not shown in
The server computer 500A can host computing applications, processes and applets for the generation, authentication, encryption, and communication of data and applications, and may cooperate with other server computing environments (not shown in
It should also be appreciated that the computing architecture shown in
The disclosure presented herein also encompasses the subject matter set forth in the following clauses:
Clause 1. A computer-implemented method for establishing a network session in a remote desktop infrastructure environment, the method comprising: utilizing an Interactive Connectivity Establishment (ICE) protocol to identify a first network address for use by a remote desktop client computer to communicate with a remote desktop session host; utilizing the ICE protocol to identify a second network address for use by the remote desktop session host to communicate with the remote desktop client computer; and establishing a first network connection between the remote desktop client computer and the remote desktop session host using the first network address and the second network address, the network connection comprising a remote desktop protocol over user datagram protocol (UDP) connection.
Clause 2. The computer-implemented method of clause 1, wherein the first network connection between the remote desktop client computer and the remote desktop session host comprises a network connection between the remote desktop client computer and a media relay service implementing a Traversal Using Relays around NAT (TURN) protocol and a network connection between the remote desktop session host and the media relay service.
Clause 3. The computer-implemented method of clauses 1 or 2, wherein the first network connection between the remote desktop client and the remote desktop session host does not utilize a media relay service.
Clause 4. The computer-implemented method of any of clauses 1-3, wherein first network connection comprises a first remote desktop protocol transport channel
Clause 5. The computer-implemented method of any of clauses 1-4, further comprising: utilizing the ICE protocol to identify a third network address for use by the remote desktop client computer to communicate with the remote desktop session host; utilizing the ICE protocol to identify a fourth network address for use by the remote desktop session host to communicate with the remote desktop client computer; and establishing a second network connection between the remote desktop client computer and the remote desktop session host using the third network address and the fourth network address, the network connection comprising a remote desktop protocol over UDP connection.
Clause 6. The computer-implemented method of any of clauses 1-5, wherein second network connection comprises a second remote desktop protocol transport channel.
Clause 7. The computer-implemented method of any of clauses 1-6, further comprising: determining that the ICE protocol cannot be utilized to establish the first network connection between the remote desktop client computer and the remote desktop session host; and responsive to determining that the ICE protocol cannot be utilized, establish a first Transmission Control Protocol (TCP) WebSocket connection between the remote desktop client application and a gateway and establish a second TCP Web Socket connection between the remote desktop session host and the gateway for enabling communication between the remote desktop client computer and the remote desktop session host.
Clause 8. A computer-readable storage medium having computer executable instructions stored thereupon which, when executed by a computer, cause the computer to: utilize an Interactive Connectivity Establishment (ICE) protocol to identify a plurality of client candidate network addresses for use by a remote desktop client computer to communicate with a remote desktop session host; receive a plurality of server candidate network addresses for use by the remote desktop session host to communicate with the remote desktop client computer; select a pair of network addresses from the plurality of client candidate network addresses and the plurality of server candidate network addresses using the ICE protocol; and establish a first network connection between the remote desktop client computer and the remote desktop session host using the selected pair of network addresses, the network connection comprising a remote desktop protocol over user datagram protocol (UDP) connection.
Clause 9. The computer-readable storage medium of clause 8, wherein the first network connection between the remote desktop client computer and the remote desktop session host comprises a network connection between the remote desktop client computer and a media relay service implementing a Traversal Using Relays around NAT (TURN) protocol and a network connection between the remote desktop session host and the media relay service.
Clause 10. The computer-readable storage medium of clauses 8 or 9, wherein the first network connection between the remote desktop client and the remote desktop session host does not utilize a media relay service.
Clause 11. The computer-readable storage medium of any of clauses 8-10, wherein first network connection comprises a first remote desktop protocol transport channel.
Clause 12. The computer-readable storage medium of any of clauses 8-11, having further computer-executable instructions stored thereupon which, when executed by the computer, cause the computer to: receive a second plurality of server candidate network addresses for use by the remote desktop session host to communicate with the remote desktop client computer; utilize the ICE protocol to identify a second plurality of client candidate network addresses for use by the remote desktop client computer to communicate with the remote desktop session host; select a second pair of network addresses from the second plurality of client candidate network addresses and the second plurality of server candidate network addresses using the ICE protocol; and establish a second network connection between the remote desktop client computer and the remote desktop session host using the selected second pair of network addresses, the network connection comprising a remote desktop protocol over UDP connection.
Clause 13. The computer-readable storage medium of any of clauses 8-12, wherein the second network connection between the remote desktop client computer and the remote desktop session host comprises a network connection between the remote desktop client computer and a media relay service implementing a Traversal Using Relays around NAT (TURN) protocol and a network connection between the remote desktop session host and the media relay service.
Clause 14. The computer-readable storage medium of any of clauses 8-13, wherein second network connection comprises a second remote desktop protocol transport channel.
Clause 15. A computing device, comprising: at least one processor; and a computer-readable storage medium having computer-executable instructions stored thereupon which, when executed by the at least one processor, cause the computing device to: receive a plurality of client candidate network addresses at a remote desktop server application; utilize an Interactive Connectivity Establishment (ICE) protocol to identify a plurality of server candidate network addresses for use by the remote desktop server application to communicate with a remote desktop client application; transmit the plurality of server candidate network addresses from the remote desktop server application to the remote desktop client application; select a pair of network addresses from the plurality of client candidate network addresses and the plurality of server candidate network addresses using the ICE protocol; and establish a first network connection between the remote desktop client application and the remote desktop server application using the selected pair of network addresses, the network connection comprising a remote desktop protocol over user datagram protocol (UDP) connection.
Clause 16. The computing device of clause 15, wherein the first network connection between the remote desktop client computer and the remote desktop session host comprises a network connection between the remote desktop client computer and a media relay service implementing a Traversal Using Relays around NAT (TURN) protocol and a network connection between the remote desktop session host and the media relay service.
Clause 17. The computing device of clauses 15 or 16, wherein the first network connection between the remote desktop client and the remote desktop session host does not utilize a media relay service.
Clause 18. The computing device of any of clauses 15-17, wherein the computer-readable storage medium has further computer-executable instructions stored thereupon which, when executed by the at least one processor, cause the computing device to: utilize the ICE protocol to identify a second plurality of server candidate network addresses for use by the remote desktop server application to communicate with the remote desktop client application; transmit the second plurality of server candidate network addresses to the remote desktop client application over the first network connection; receive a second plurality of client candidate network addresses from the remote desktop client application over the first network connection; select a second pair of network addresses from the second plurality of client candidate network addresses and the second plurality of server candidate network addresses using the ICE protocol; and establish a second network connection between the remote desktop client application and the remote desktop server application using the selected second pair of network addresses, the network connection comprising a remote desktop protocol over UDP connection.
Clause 19. The computing device of any of clauses 15-18, wherein the second network connection between the remote desktop client application and the remote desktop server application comprises a network connection between the remote desktop client application and a media relay service implementing a Traversal Using Relays around NAT (TURN) protocol and a network connection between the remote desktop server application and the media relay service.
Clause 20. The computing device of any of clauses 15-19, wherein second network connection comprises a second remote desktop protocol transport channel.
Based on the foregoing, it should be appreciated that technologies for performing session establishment in remote desktop infrastructure environments have been disclosed herein. Although the subject matter presented herein has been described in language specific to computer structural features, methodological and transformative acts, specific computing machinery, and computer readable media, it is to be understood that the subject matter set forth in the appended claims is not necessarily limited to the specific features, acts, or media described herein. Rather, the specific features, acts and mediums are disclosed as example forms of implementing the claimed subject matter.
The subject matter described above is provided by way of illustration only and should not be construed as limiting. Various modifications and changes can be made to the subject matter described herein without following the example configurations and applications illustrated and described, and without departing from the scope of the present disclosure, which is set forth in the following claims.
