Patent Description:
To facilitate increased utilization of data center resources, virtualization technologies may allow a single physical computing machine to host one or more virtual desktop instances that appear and operate as independent computer machines to a connected computer user. With virtualization, the single physical computing device can create, maintain or delete virtual machines in a dynamic manner. In turn, users can request computer resources from a data center and be provided with varying numbers of virtual machine resources on an "as needed" basis or at least on an "as requested" basis. With the increased use of cloud computing resources, some cloud computing environments running virtual desktop instances may be inefficient in managing resource allocation and providing communication capabilities to accommodate customer-requested functionalities associated with the virtual desktop instances.

<CIT> describes a system and method for zero client communications. A zero client device includes a housing, and in the housing, a transcoding processing unit (transcoder) and a communications processing unit coupled to the transcoder. The transcoder is configured to receive input data from human interface device(s), encode the input data, and provide the encoded input data to the communications processing unit for transmission over a network to a server. The communications processing unit is configured to receive the encoded input data from the transcoder, transmit the encoded input data over the network to the server, receive output data from the server, and send the output data to the transcoder. The transcoder is further configured to receive the output data from the communications processing unit, decode the output data, and send the decoded output data to at least one of the human interface devices.

<CIT> describes measuring a latency of a plurality of service requests in a cloud-network; determining a mean latency; and determining a variance of the plurality of service requests; comparing the mean latency to a first threshold; comparing the variance to a second threshold; and determining that the cloud-network is deficient if either the mean latency exceeds the first threshold or the variance exceeds the second threshold.

<CIT> discusses a remote client that is allowed to access at least a part of a connection service located on alternate sources other than the primary remote presentation server. The remote presentation virtual channels may be split into multiple connections with the purpose of allowing better flow control. The system may be implemented in a virtual machine environment for cases in which the data to be transferred through a data channel is located in the host virtual machine partition but the remote endpoint is located on the guest virtual machine partition.

Particular aspects and embodiments are set out in the appended independent and dependent claims.

A virtual machine image contains an operating system (e.g., Linux) and other data needed to launch a virtual machine in a virtual environment. The virtual machine image is similar to a physical computer's disk volume, and may include a file system, the operating system and other components needed to boot up as a machine. In order to launch a virtual machine, hardware needs to be selected. The hardware selection may be accomplished through instance types, which may allow a variety of different sizes of memory, CPU capacity, I/O performance, and so forth. The combination of the virtual machine image and the instance type can be used to create an "instance" or a virtual machine, which may be launched on a cloud computing resource, such as a host server computer in a multi-tenant network environment. As used herein, the terms "virtual machine" and "virtual machine instance" are interchangeable.

As used herein, the term "virtual desktop infrastructure" refers to an environment with a plurality of server computers, where a desktop operating system can run on a virtual machine instance launched on at least one of the plurality of server computers. The virtual machine instance running a desktop operating system can be referred to as a virtual desktop instance. Although at least some of the embodiments disclosed herein are described in the context of a virtual desktop infrastructure provided by a service provider, further embodiments can be used with an on-premises network, or a with a combination of a service-provider network and an on-premises network.

The following description is directed to techniques and solutions supporting creating a virtual desktop infrastructure environment that can use multiple communication protocols. More specifically, a user of the service provider environment may use a client computing device to access a virtual desktop instance running on a virtual machine. Access to the virtual desktop instance may be provided using a communication channel associated with a first communication protocol. The user may request a functionality (e.g., USB redirection), which may be unsupported by the first communication protocol. A protocol selection service of the service provider may be used to select another (second) communication protocol, which supports the requested functionality. The protocol selection may be performed using a protocol selection table and/or one or more policy documents (e.g., a global policy document and/or a policy document associated with a customer account of the user). The user may be authenticated for using the second communication protocol, and upon authentication, a second communication channel may be established for handling the requested functionality, while the first communication channel is still open. In an example embodiment, one or more network health characteristics for the service provider environment network (e.g., network latency) and/or one or more software and/or hardware characteristics (e.g., CPU, memory, GPU availability, operating system version, and so forth) of the client computing device and the server computer running the virtual desktop instance may be used to determine whether all communications should be switched over to the second communication channel associated with the second communication protocol, or whether communications should be split between the first and second communication channels. In this regard, multiple communication protocols may be used to support access to the virtual desktop instance by the client computing device.

<FIG> is a diagram of an example network environment supporting virtual desktop infrastructure in a service provider, in accordance with an embodiment of the disclosure. Referring to <FIG>, the network environment <NUM> may include a service provider <NUM> in communication with a client computing device <NUM> via the network <NUM>. The service provider <NUM> may be a multi-tenant cloud network environment where one or more clients (e.g., a user of the client computing device <NUM>) may run one or more virtual machine instances (VMIs) on one or more of server computers (e.g., instance <NUM> on server computer <NUM>) (even though only a single server computer <NUM> is illustrated in <FIG>, multiple server computers can be used by the service provider <NUM>). For example, the virtual machine instance <NUM> may execute an instance of an operating system and application software to create a virtual desktop instance. Each virtual desktop instance running on one or more server computers can be accessed by one or more client computing devices, such as client computing device <NUM>. The server computers (e.g., <NUM>) may be, for example, client servers operated by (or on behalf of) one or more clients of the service provider <NUM>. The service provider <NUM> may further comprise an endpoint service <NUM> with a plurality of endpoints <NUM>,. , <NUM>, and a protocol selection service (PSS) <NUM>.

The virtual desktop instance <NUM> may also include a protocol agent <NUM>. The protocol agent <NUM> may comprise suitable logic, interfaces, and/or code and may be operable to manage streaming of the virtual desktop instance <NUM>, including setting up new communication ports for new communication links and/or terminate existing communication links and ports. In an example embodiment, the protocol agent <NUM> may run as an application on the instance <NUM>.

The server computer <NUM> may include an instance manager <NUM>. The instance manager <NUM> may be on the same server computer (e.g., <NUM>) as the virtual desktop instance <NUM>, or on a separate computer. The instance manager <NUM> may track progress of the instances executed on the server computers (e.g., <NUM>), monitor and coordinate the storage of data created by the user while interacting with the instances (e.g., <NUM>) via the client computing devices, and monitor the overall health and state of the server computers of the service provider <NUM> and of the remote computing applications (e.g., <NUM>) running on client computing devices (e.g., <NUM>). The instance manager <NUM> can be part of a management plane (e.g., management server computer), as illustrated in <FIG>.

The server computer <NUM> may further include a hypervisor <NUM> and server capabilities block <NUM>. The hypervisor <NUM> can be configured to enable the execution of multiple instances (e.g., instance <NUM>) on the server computer <NUM>. The hypervisor is further discussed in reference to <FIG> and <FIG> below. The server computer <NUM> may have varied local computing resources such as central processing units and architectures, memory, mass storage, graphics processing units (GPUs), communication network availability and bandwidth, etc. Information on various computing resources of the server computer <NUM> are designated as server capabilities <NUM>.

The client computing device <NUM> may be used for providing access to a remote operating system (e.g., virtual desktop instance <NUM>) and applications to a user. In an illustrative embodiment, the client computing device <NUM> can correspond to a wide variety of computing devices including personal computing devices, laptop computing devices, hand-held computing devices, terminal computing devices, mobile devices (e.g., mobile phones, tablet computing devices, electronic book readers, etc.), wireless devices, various electronic devices and appliances, and the like. In an illustrative embodiment, the client computing device <NUM> includes necessary hardware and software components for establishing communications over a communication network <NUM>, such as a wide area network or local area network. For example, the client computing device <NUM> may be equipped with networking equipment and browser software applications that facilitate communications via the Internet or an intranet with one or more of the server computers <NUM> in the service provider <NUM>. The client computing device <NUM> may have varied local computing resources such as central processing units and architectures, memory, mass storage, graphics processing units (GPUs), communication network availability and bandwidth, etc. Information on various computing resources of the client computing device <NUM> are designated as client capabilities <NUM>.

In one embodiment, the client computing device <NUM> may run a remote computing application <NUM>. The remote computing application <NUM> may request access to a virtual desktop instance (e.g., <NUM>) hosted by the server computer <NUM> of the service provider <NUM>. The remote computing application <NUM> may also manage the remote computing session between the client computing device <NUM> and the service provider <NUM>. Additionally, the remote computing application <NUM> may facilitate establishing a connection between one or more communication protocol endpoints (e.g., a communication link using one of a plurality of communication protocols) and a device component (as illustrated in greater detail in <FIG>).

The endpoint service <NUM> may include a plurality of endpoints <NUM>,. Each of the endpoints <NUM>,. , <NUM> may comprise suitable logic, circuitry, interfaces, and/or code and may be operable to provide authentication of one or more service provider clients (e.g., user of the client device <NUM>) and facilitate communication between the client computing device <NUM> and the server computers (e.g., <NUM>). Each of the endpoints <NUM>,. , <NUM> may comprise a secure gateway, router, or another network device operable to use one or more communication links associated with at least one of a plurality of communication protocols (e.g., communication links <NUM>,. , <NUM> and <NUM>,. , <NUM> associated with communication protocols <NUM>,. Additionally, each of the endpoints within the endpoint service <NUM> may be a cloud endpoint located in one of a plurality of separate regions (e.g., separate geographic regions) associated with the service provider <NUM>. An example communication sequence for establishing a secure link between the client computing device <NUM>, the endpoint service <NUM> and the server computer <NUM> is described herein below in reference to <FIG>.

The protocol selection service (PSS) <NUM> may comprise suitable logic, circuitry, interfaces, and/or code and may be operable to select a communication protocol and facilitate establishing of a communication link (or channel) associated with the communication protocol between the client computing device <NUM> and the server computer <NUM>. The PSS <NUM> may also use a policy document (e.g., <NUM> and/or <NUM>), which may specify one or more policies in connection with protocol selection functionalities. For example, the customer account policy <NUM> may specify one or more communication protocols that a customer (e.g., user of the computing device <NUM>) is authorized to use for a specific functionality associated with accessing the virtual desktop instance <NUM>. Example functionalities which may be requested by a user of client device <NUM> in connection with access to the virtual desktop instance <NUM> may include a multimedia data processing functionality, a USB data processing functionality (e.g., USB redirection), a virtual channel data processing functionality, and a keyboard data processing functionality. Example communication protocols which may be used in connection with requested functionalities may include PC-over-IP (PCoIP) communication protocol and Remote Desktop Protocol (RDP).

The global policy <NUM> may specify protocol selection policies that can be used in connection with all users of the service provider environment <NUM>. The policy documents <NUM> and <NUM> may be updated by, for example, an administrator via the administrative portal <NUM>. The PSS <NUM> may further use a network monitor <NUM> and a protocol decision table <NUM> during selection of a communication protocol as well as to determine whether to simultaneously maintain open two or more communication links (e.g., each associated with a different communication protocol) or whether to switch over all communication traffic between the computing device <NUM>, the endpoint service <NUM> and the server computer <NUM> using a single communication link. For example, the PSS <NUM> may receive information about the client capabilities <NUM>, the server capabilities <NUM> and information from the network monitor <NUM>, and use the received information to determine whether to switch communications from an existing communication link based on one communication protocol to a new communication link based on another communication protocol. The information supplied from the network monitor may include health information about the communication network within the service provider <NUM>, such as network latency, bandwidth, and so forth.

In accordance with an example embodiment of the disclosure, the PSS <NUM> may be implemented as a stand-alone service within the service provider <NUM> (as illustrated in <FIG>) or it may be implemented as a code library (i.e., software) within one or more of the server computers (e.g., <NUM>).

<FIG> is a block diagram of an example client computing device authentication for accessing a virtual desktop instance using one or more communication protocols, in accordance with an embodiment of the disclosure. Referring to <FIG>, a user of device <NUM> may be a client of the service provider <NUM> and may use server computer <NUM> to run a virtual desktop instance <NUM> (e.g., the user may obtain a customer account from the service provider <NUM> in exchange for a fee, giving the user the right to launch a virtual desktop on one or more instances running on one or more server computers such as server computer <NUM>). In other words, the virtual desktop instance <NUM> may be associated with a customer account of the user of device <NUM>. The user may have more than one virtual desktop instances at a time, however, may be able to login and use one virtual desktop instance at a time.

In an example communication exchange for obtaining access to the virtual desktop instance <NUM>, the user of the client computing device <NUM> may initiate communication with the endpoint service <NUM> by sending (at ref# <NUM>) a login ID (user name) and password (or any other login/authentication credentials associated with a customer account) to the endpoint <NUM>. The endpoint <NUM> may authenticate the user and may send back (at ref# <NUM>) an authentication token <NUM> to the client computing device <NUM>. The client device <NUM> may then send the authentication token <NUM> (at ref# <NUM>) to the endpoint <NUM>. The endpoint <NUM> may forward the token (at ref# <NUM>) to endpoint <NUM> to confirm the token belongs to the requesting user and the user has a valid customer account. A confirmation the user is authenticated may be sent (at ref# <NUM>) from endpoint <NUM> to endpoint <NUM>. Endpoint <NUM> may then return (at ref# <NUM>) virtual desktop instance identification <NUM> (which may include a port number, such as a port used to establish communication link <NUM> using protocol <NUM>), a gateway IP address <NUM>, and a secure token <NUM>. The gateway IP address <NUM> may be an IP address for endpoint <NUM>, which can operate as a proxy between the client computing device <NUM> and the virtual desktop instance <NUM> while using communication links <NUM> and <NUM>. The secure token <NUM> may be used for authenticating the client device <NUM> to use the endpoint <NUM> as a proxy to communicate with the virtual desktop instance <NUM> using at least one of a plurality of available communication protocols (e.g., protocol <NUM>).

The virtual desktop instance identification <NUM>, the gateway IP address <NUM>, and the secure token <NUM> may be communicated to endpoint <NUM> (at ref# <NUM>). The endpoint <NUM> may communicate the secure token <NUM> (at ref# <NUM>) to endpoint <NUM>, which has issued the token. Endpoint <NUM> may authenticate the token <NUM> and may provide a confirmation of the authentication back to endpoint <NUM> (at ref# <NUM>). The protocol selection service <NUM> may then communicate with the protocol agent <NUM> at the virtual desktop instance <NUM> (e.g., using virtual desktop instance identification <NUM>) and have the protocol agent <NUM> open a new port for establishing a communication link <NUM> using communication protocol <NUM>. The communication protocol <NUM> may be selected by the protocol selection service using a protocol decision table <NUM>. More specifically, the protocol decision table <NUM> may associate one or more device functionalities (e.g., functionalities requested or necessary for the device <NUM> to access the instance <NUM>) with one or more communication protocols selected from a plurality of available communication protocols.

In an example embodiment, the PSS <NUM> may select the communication protocol for communication links <NUM> and <NUM> using a global policy document and/or a customer account policy <NUM>. The policy documents <NUM>/<NUM> may specify which communication protocol to use for a specific functionality required by computing device <NUM> to access the virtual desktop instance <NUM>. The PSS <NUM> may also authenticate the user of client device <NUM> to use a given communication protocol, prior to establishing a link using such protocol. The user authentication may be performed using, for example, the customer account policy <NUM>, which may specify which protocols the client/user is authorized to use within the service provider environment.

After the protocol agent <NUM> opens a new port, communication links <NUM> and <NUM> may be established (or links <NUM>, <NUM> in <FIG>) using communication protocol <NUM> for providing the client device <NUM> access to the virtual desktop instance <NUM>. In another example embodiment, the PSS <NUM> may detect a new functionality requested by the client device <NUM>, where the new functionality is unsupported by the communication protocol <NUM> associated with communication channels/links <NUM>/<NUM>. For example, the user of device <NUM> may use an USB memory stick in connection with accessing instance <NUM>, however, USB redirection may be unsupported by communication protocol <NUM>. The communication sequence indicated by reference numbers <NUM>-<NUM> may take place again, however, endpoint <NUM> may return gateway IP address <NUM> identifying endpoint <NUM>, and a secure token <NUM> authorizing the user and client device <NUM> to access endpoint <NUM> as a proxy between device <NUM> and virtual desktop instance <NUM> using communication links <NUM>/<NUM> associated with communication protocol <NUM>.

The PSS <NUM> may select communication protocol <NUM> so that it supports the requested functionality, which is unsupported by protocol <NUM>. The selection of protocol <NUM> may be based on the protocol decision table <NUM>, the global policy <NUM>, and/or the customer account policy <NUM>. As an alternative, the new protocol <NUM> may also be selected by the user and communicated to the PSS <NUM> via the endpoint <NUM>. Similarly to communication link <NUM>, the protocol agent <NUM> may establish a new port associated with protocol <NUM>, so that the PSS <NUM> (or the protocol agent <NUM>) may open new communication links <NUM>/<NUM> (or <NUM>/<NUM> in <FIG>) associated with communication protocol <NUM>. In this regard, the client computing device <NUM> may access the virtual desktop instance <NUM> concurrently using at least two different communication protocols (i.e., communication links <NUM>,. , <NUM> are open and used simultaneously).

In yet another example embodiment, the PSS <NUM> may use the client capabilities <NUM>, the server capabilities <NUM> and/or information from the network monitor <NUM> (e.g., network latency information) to determine whether to offload (or switch over) communication traffic from one communication link of a first protocol type (e.g., links <NUM>/<NUM> using protocol <NUM>) to another communication link of a second protocol type (e.g., links <NUM>/<NUM> using protocol <NUM>). Such communication distribution functionality may be performed automatically or upon network administrator approval (e.g., via the portal <NUM>). Additionally, any time a new communication protocol is used (e.g., a new communication link is established to handle certain functionality) or communication traffic is switched (fully or partially) from one protocol to another, a notification may be displayed at the client computing device <NUM>.

<FIG> is a block diagram of an example client computing device running a remote computing application that can associate a plurality of communication protocols with a plurality of device components, in accordance with an embodiment of the disclosure. Referring to <FIG>, there is illustrated the client computing device <NUM> using multiple communication links <NUM>,. , <NUM> using different communication protocols <NUM>,. Each communication link <NUM>,. , <NUM> may be used to handle a specific type of functionality or communication used by the client device <NUM> to access a virtual desktop instance. Additionally, communication links <NUM>,. , <NUM> may enter the client computing device <NUM> at corresponding protocol endpoints <NUM>,. In accordance with an example embodiment of the disclosure, the remote computing application <NUM> may determine one or more device components associated with a given protocol and then direct communication traffic from such protocol to the one or more components. For example, if communication link <NUM> uses RDP protocol to handle USB redirection, then the remote computing application <NUM> may associate protocol endpoint <NUM> with device component <NUM> (e.g., a USB port and associated components providing USB access functionality).

<FIG> is an example system diagram showing a plurality of virtual machine instances running in a multi-tenant environment, using a protocol selection service, in accordance with an example embodiment of the disclosure. More specifically, <FIG> is a computing system diagram of a network-based service provider <NUM> that illustrates one environment in which embodiments described herein can be used. By way of background, the service provider <NUM> (i.e., the cloud provider) is capable of delivery of computing and storage capacity as a service to a community of end recipients (e.g., tenants or customers). The service provider <NUM> may be the same as the service provider <NUM> illustrated in <FIG>.

In an example embodiment, the service provider <NUM> can be established for an organization by or on behalf of the organization. That is, the service provider <NUM> may offer a "private cloud environment. " In another embodiment, the service provider <NUM> supports a multi-tenant environment, wherein a plurality of customers operate independently (i.e., a public cloud environment). Generally speaking, the service provider <NUM> can provide the following models: Infrastructure as a Service ("IaaS"), Platform as a Service ("PaaS"), and/or Software as a Service ("SaaS"). Other models can be provided. For the IaaS model, the service provider <NUM> can offer computers as physical or virtual machines and other resources. The virtual machines can be run as guests by a hypervisor, as described further below. The PaaS model delivers a computing platform that can include an operating system, programming language execution environment, database, and web server. Application developers can develop and run their software solutions on the service provider platform without the cost of buying and managing the underlying hardware and software. The SaaS model allows installation and operation of application software in the service provider. In some embodiments, end users access the service provider <NUM> using networked customer devices, such as desktop computers, laptops, tablets, smartphones, etc. running web browsers or other lightweight customer applications. Those skilled in the art will recognize that the service provider <NUM> can be described as a "cloud" environment.

The particular illustrated service provider <NUM> includes a plurality of server computers 402A-402D. While only four server computers are shown, any number can be used, and large centers can include thousands of server computers. The server computers 402A-402D can provide computing resources for executing software instances 406A-406D. In one embodiment, the instances 406A-406D are virtual machines. As known in the art, a virtual machine is an instance of a software implementation of a machine (i.e., a computer) that executes applications like a physical machine. In the example, each of the server computers 402A-402D can be configured to execute a hypervisor <NUM> or another type of program configured to enable the execution of multiple instances <NUM> on a single server. For example, each of the servers 402A-402D can be configured (e.g., via the hypervisor <NUM>) to support one or more virtual machine partitions, with each virtual machine partition capable of running a virtual machine instance (e.g., server computer 402A could be configured to support three virtual machine partitions each running a corresponding virtual machine instance). Additionally, each of the instances <NUM> can be configured to execute one or more applications.

The service provider <NUM> may also comprise a protocol selection service <NUM>, which may have the functionalities described herein in connection with the PSS <NUM>. The protocol selection service <NUM> may be implemented as a stand-alone service within the provider <NUM>, as a dedicated server (similar to the servers 402A-402D), as a code library within one or more of the servers <NUM>, and/or may be implemented as part of the server computer <NUM> that performs management functions. For example, the protocol selection service <NUM> may be implemented as part of the management component <NUM> (as seen in <FIG>).

It should be appreciated that although the embodiments disclosed herein are described primarily in the context of virtual machines, other types of instances can be utilized with the concepts and technologies disclosed herein. For instance, the technologies disclosed herein can be utilized with storage resources, data communications resources, and with other types of computing resources. The embodiments disclosed herein might also execute all or a portion of an application directly on a computer system without utilizing virtual machine instances.

One or more server computers <NUM> can be reserved for executing software components for managing the operation of the server computers <NUM>, the instances <NUM>, the hypervisors <NUM>, and/or the protocol selection service <NUM>. For example, the server computer <NUM> can execute a management component <NUM>. A customer can access the management component <NUM> to configure various aspects of the operation of the instances <NUM> purchased by the customer. For example, the customer can purchase, rent or lease instances and make changes to the configuration of the instances. The customer can also specify settings regarding how the purchased instances are to be scaled in response to demand.

The server computer <NUM> may further comprise memory <NUM>, which may be used as processing memory by the protocol selection service <NUM>. An auto scaling component <NUM> can scale the instances <NUM> based upon rules defined by the customer. In one embodiment, the auto scaling component <NUM> allows a customer to specify scale-up rules for use in determining when new instances should be instantiated and scale-down rules for use in determining when existing instances should be terminated. The auto scaling component <NUM> can consist of a number of subcomponents executing on different server computers <NUM> or other computing devices. The auto scaling component <NUM> can monitor available computing resources over an internal management network and modify resources available based on need.

A deployment component <NUM> can be used to assist customers in the deployment of new instances <NUM> of computing resources. The deployment component can have access to account information associated with the instances, such as who is the owner of the account, credit card information, country of the owner, etc. The deployment component <NUM> can receive a configuration from a customer that includes data describing how new instances <NUM> should be configured. For example, the configuration can specify one or more applications to be installed in new instances <NUM>, provide scripts and/or other types of code to be executed for configuring new instances <NUM>, provide cache logic specifying how an application cache should be prepared, and other types of information. The deployment component <NUM> can utilize the customer-provided configuration and cache logic to configure, prime, and launch new instances <NUM>. The configuration, cache logic, and other information may be specified by a customer using the management component <NUM> or by providing this information directly to the deployment component <NUM>. The instance manager (e.g., <NUM> in <FIG>) can be considered part of the deployment component <NUM>.

Customer account information <NUM> can include any desired information associated with a customer of the multi-tenant environment. For example, the customer account information can include a unique identifier for a customer, a customer address, billing information, licensing information, customization parameters for launching instances, scheduling information, auto-scaling parameters, previous IP addresses used to access the account, and so forth.

A network <NUM> can be utilized to interconnect the server computers 402A-402D and the server computer <NUM>. The network <NUM> can be a local area network (LAN) and can be connected to a Wide Area Network (WAN) <NUM> so that end-users can access the service provider <NUM>. It should be appreciated that the network topology illustrated in <FIG> has been simplified and that many more networks and networking devices can be utilized to interconnect the various computing systems disclosed herein.

<FIG> shows further details of an example system including a plurality of management components associated with a control plane, which may be used to provide protocol selection according to one embodiment. More specifically, <FIG> illustrates in further detail the management component <NUM>, which may implement the protocol selection service <NUM> within the multi-tenant environment of the service provider <NUM>.

In order to access and utilize instances (such as instances <NUM> of <FIG>), a customer device can be used. The customer device <NUM> can be any of a variety of computing devices, mobile or otherwise, including a cell phone, smartphone, handheld computer, Personal Digital Assistant (PDA), desktop computer, etc. The customer device <NUM> can communicate with the service provider <NUM> through an end point <NUM>, which can be a DNS address designed to receive and process application programming interface (API) requests. In particular, the end point <NUM> can be a web server configured to expose an API. Using the API requests, a customer device <NUM> can make requests to implement any of the functionality described herein or to access one or more services provided by the service provider <NUM>. Other services <NUM>, which can be internal to the service provider <NUM>, can likewise make API requests to the end point <NUM>. The API requests from the client can pass through the admission control <NUM> and onto the protocol selection service <NUM> in order to access protocol selection-related functionalities of the service provider <NUM>.

Other general management services that may or may not be included in the service provider <NUM> (and/or within the management component <NUM>) include an admission control <NUM>, e.g., one or more computers operating together as an admission control web service. The admission control <NUM> can authenticate, validate and unpack the API requests for service or storage of data within the service provider <NUM>. The capacity tracker <NUM> is responsible for determining how the servers need to be configured in order to meet the need for the different instance types by managing and configuring physical inventory in terms of forecasting, provisioning, and real-time configuration and allocation of capacity. The capacity tracker <NUM> maintains a pool of available inventory in a capacity pool database <NUM>. The capacity tracker <NUM> can also monitor capacity levels so as to know whether resources are readily available or limited.

An instance manager <NUM> controls launching and termination of virtual machine instances in the network. When an instruction is received (such as through an API request) to launch an instance, the instance manager <NUM> pulls resources from the capacity pool <NUM> and launches the instance on a decided upon host server computer. Similar to the instance manager are the storage manager <NUM> and the network resource manager <NUM>. The storage manager <NUM> relates to initiation and termination of storage volumes, while the network resource manager <NUM> relates to initiation and termination of routers, switches, subnets, etc. A network of partitions <NUM> is described further in relation to <FIG>, and includes a physical layer upon which the instances are launched.

The protocol selection service <NUM> may perform the protocol selection functionalities described herein (e.g., the functionalities described in reference to the PSS <NUM>). The PSS <NUM> may communicate with the admission control <NUM> (e.g., to receive new functionality requests and requests for establishing new communication links or switch communication from one protocol type to another), with the network of partitions <NUM> (e.g., to access a virtual desktop instance running on a server computer), the policy documents <NUM>/<NUM>, and the protocol decision table <NUM> (e.g., as described in connection with <FIG>).

<FIG> shows an example of a plurality of host computers, routers, and switches - which are hardware assets used for running virtual machine instances - with the host computers having protocol selection-related functionalities that may be configured according to one embodiment. More specifically, <FIG> illustrates the network of partitions <NUM> and the physical hardware associated therewith. The network of partitions <NUM> can include a plurality of data centers, such as data centers 610a,. , 610n, coupled together by routers, such as router <NUM>.

The router <NUM> reads address information in a received packet and determines the packet's destination. If the router decides that a different data center contains a host server computer, then the packet is forwarded to that data center. If the packet is addressed to a host in the data center 610a, then it is passed to a network address translator (NAT) <NUM> that converts the packet's public IP address to a private IP address. The NAT <NUM> also translates private addresses to public addresses that are bound outside of the data center 610a. Additional routers <NUM> can be coupled to the NAT <NUM> to route packets to one or more racks <NUM> of host server computers. Each rack <NUM> can include a switch <NUM> coupled to multiple host server computers. A particular host server computer is shown in an expanded view at <NUM>.

Each host <NUM> has underlying hardware <NUM>. Running a layer above the hardware <NUM> is a hypervisor or kernel layer <NUM>. The hypervisor or kernel layer <NUM> can be classified as a type <NUM> or type <NUM> hypervisor. A type <NUM> hypervisor runs directly on the host hardware <NUM> to control the hardware and to manage the guest operating systems. A type <NUM> hypervisor runs within a conventional operating system environment. Thus, in a type <NUM> environment, the hypervisor can be a distinct layer running above the operating system and the operating system interacts with the system hardware. Different types of hypervisors include Xen-based, Hyper-V, ESXi/ESX, Linux, etc., but other hypervisors can also be used. In an example embodiment, the hypervisor layer <NUM> may include the DFS software <NUM>, which may be used to install DSNs or DMNs, as described herein.

A management layer <NUM> can be part of the hypervisor or separated therefrom, and generally includes device drivers needed for accessing the hardware <NUM>. The partitions <NUM> are logical units of isolation by the hypervisor. Each partition <NUM> can be allocated its own portion of the hardware layer's memory, CPU allocation, storage, etc. Additionally, each partition can include a virtual machine and its own guest operating system (e.g., VMI1 may be running on partition <NUM> and VMIn may be running on partition n). As such, each partition <NUM> is an abstract portion of capacity designed to support its own virtual machine independent of the other partitions. One or more of the VMIs (VMI1,. , VMIn) on partitions <NUM> may also execute virtual desktop instances (VDIs) associated with a customer account, similar to the VDI <NUM> in <FIG>.

<FIG> are flowcharts of example methods of selecting a communication protocol for a virtual desktop instance in a service provider environment, in accordance with an embodiment of the disclosure. Referring to <FIG> and <FIG>, the example method <NUM> may start at <NUM>, when the protocol selection service <NUM> may provide to a client computing device (e.g., <NUM>), access to a virtual desktop instance (e.g., <NUM>) running on a server computer (e.g., <NUM>) in a service provider environment using a first communication channel associated with a first communication protocol. For example, the endpoint service <NUM> and the client device <NUM> may perform the secure authentication sequence as described in reference to <FIG>, the PSS <NUM> may authenticate the device <NUM> for use of communication protocol <NUM>, and then establish communication links <NUM>/<NUM> based on the communication protocol <NUM> for accessing the virtual desktop instance <NUM>.

At <NUM>, the PSS <NUM> may detect a request for a functionality from a user of the client computing device <NUM>, where the requested functionality is unsupported by the first communication protocol (i.e., protocol <NUM> associated with the existing communication links <NUM>/<NUM>). For example, the requested functionality may be one of a multimedia data processing functionality, a USB data processing functionality, a virtual channel data processing functionality, and/or a keyboard data processing functionality. At <NUM>, the PSS <NUM> may select based on the requested functionality, a second communication protocol from a plurality of available communication protocols, the second communication protocol supporting the requested functionality. The PSS <NUM> may select communication protocol <NUM> so that it supports the requested functionality, which is unsupported by protocol <NUM>. The selection of protocol <NUM> may be based on the protocol decision table <NUM>, the global policy <NUM>, and/or the customer account policy <NUM>. For example, at <NUM>, the PSS <NUM> may verify whether the user is authorized to use the second communication protocol (e.g., protocol <NUM>) by consulting the customer account policy <NUM> and/or the global policy <NUM>.

At <NUM>, upon successful verification, the PSS <NUM> may establish a second communication channel (e.g., <NUM>/<NUM>) between the server computer and the client computing device using the second communication protocol (e.g., protocol <NUM>), while maintaining access to the virtual desktop instance <NUM> using the first communication channel (e.g., <NUM>/<NUM>). Similarly to communication link <NUM>, the protocol agent <NUM> may establish a new port associated with protocol <NUM>, so that the PSS <NUM> (or the protocol agent <NUM>) may open new communication links <NUM>/<NUM> (or <NUM>/<NUM> in <FIG>) associated with communication protocol <NUM>.

Referring to <FIG> and <FIG>, the example method <NUM> may start at <NUM>, when the PSS <NUM> may authorize a user of a client computing device (<NUM>) to use a plurality of communication protocols available in a service provider environment. For example, the PSS <NUM> may authorize the user of the computing device <NUM> to use one or more of the available protocols <NUM>,. , N for establishing various communication links based on such protocols. At <NUM>, the PSS <NUM> may provide to the client computing device <NUM>, access to a virtual desktop instance (e.g., <NUM>) running on a server computer in the service provider environment using a first communication channel associated with a first communication protocol of the plurality of communication protocols. For example, the PSS may establish communication links <NUM>/<NUM> using communication protocol <NUM>, after the user of device <NUM> has been authenticated (e.g., based on the secure exchange described in reference to <FIG> and reference numbers <NUM>-<NUM>).

At <NUM>, the PSS <NUM> may provide to the client computing device <NUM>, at least some of the access to the virtual desktop instance <NUM> over a second communication channel (e.g., <NUM>/<NUM>) based on one or more of network latency (e.g., as measured by the network monitor <NUM>), a characteristic of the client computing device (e.g., <NUM>), or a characteristic of the server computer (e.g., <NUM>), where the second communication channel is associated with a second communication protocol of the plurality of communication protocols. For example, the PSS <NUM> may use the client capabilities <NUM>, the server capabilities <NUM> and/or information from the network monitor <NUM> (e.g., network latency information) to determine whether to offload (or switch over) communication traffic from one communication link of a first protocol type (e.g., links <NUM>/<NUM> using protocol <NUM>) to another communication link of a second protocol type (e.g., links <NUM>/<NUM> using protocol <NUM>). Such communication distribution functionality may be performed automatically or upon network administrator approval (e.g., via the portal <NUM>).

<FIG> depicts a generalized example of a suitable computing environment in which the described innovations may be implemented. Referring to <FIG>, the computing environment <NUM> is not intended to suggest any limitation as to scope of use or functionality, as the innovations may be implemented in diverse general-purpose or special-purpose computing systems. For example, the computing environment <NUM> can be any of a variety of computing devices (e.g., desktop computer, laptop computer, server computer, tablet computer, etc.).

With reference to <FIG>, the computing environment <NUM> includes one or more processing units <NUM>, <NUM> and memory <NUM>, <NUM>. In <FIG>, this basic configuration <NUM> is included within a dashed line. The processing units <NUM>, <NUM> execute computer-executable instructions. A processing unit can be a general-purpose central processing unit (CPU), processor in an application-specific integrated circuit (ASIC), or any other type of processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. For example, <FIG> shows a central processing unit <NUM> as well as a graphics processing unit or co-processing unit <NUM>. The tangible memory <NUM>, <NUM> may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two, accessible by the processing unit(s). The memory <NUM>, <NUM> stores software <NUM> implementing one or more innovations (e.g., functionalities) described herein, in the form of computer-executable instructions suitable for execution by the processing unit(s).

A computing system may have additional features. For example, the computing environment <NUM> includes storage <NUM>, one or more input devices <NUM>, one or more output devices <NUM>, and one or more communication connections <NUM>. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment <NUM>. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing environment <NUM>, and coordinates activities of the components of the computing environment <NUM>.

The tangible storage <NUM> may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium which can be used to store information in a non-transitory way and which can be accessed within the computing environment <NUM>. The storage <NUM> stores instructions for the software <NUM> implementing one or more innovations described herein.

The input device(s) <NUM> may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing environment <NUM>. The output device(s) <NUM> may be a display, printer, speaker, CD-writer, or another device that provides output from the computing environment <NUM>.

The communication connection(s) <NUM> enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media can use an electrical, optical, RF, or other carrier.

Although the operations of some of the disclosed methods are described in a particular, sequential order for convenient presentation, it should be understood that this manner of description encompasses rearrangement, unless a particular ordering is required by specific language set forth below.

Any of the disclosed methods can be implemented as computer-executable instructions stored on one or more computer-readable storage media (e.g., one or more optical media discs, volatile memory components (such as DRAM or SRAM), or non-volatile memory components (such as flash memory or hard drives)) and executed on a computer (e.g., any commercially available computer, including smart phones or other mobile devices that include computing hardware). The term computer-readable storage media does not include communication connections, such as signals and carrier waves. Any of the computer-executable instructions for implementing the disclosed techniques as well as any data created and used during implementation of the disclosed embodiments can be stored on one or more computer-readable storage media. The computer-executable instructions can be part of, for example, a dedicated software application or a software application that is accessed or downloaded via a web browser or other software application (such as a remote computing application). Such software can be executed, for example, on a single local computer (e.g., any suitable commercially available computer) or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a customer-server network (such as a cloud computing network), or other such network) using one or more network computers.

For clarity, only certain selected aspects of the software-based implementations are described. Other details that are well known in the art are omitted. For example, it should be understood that the disclosed technology is not limited to any specific computer language or program. For instance, the disclosed technology can be implemented by software written in C++, Java, Perl, JavaScript, Adobe Flash, or any other suitable programming language. Likewise, the disclosed technology is not limited to any particular computer or type of hardware. Certain details of suitable computers and hardware are well known and need not be set forth in detail in this disclosure.

It should also be well understood that any functionality described herein can be performed, at least in part, by one or more hardware logic components, instead of software.

Furthermore, any of the software-based embodiments (comprising, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.

The disclosed methods, apparatus, and systems should not be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and nonobvious features and aspects of the various disclosed embodiments, alone and in various combinations and subcombinations with one another. The disclosed methods, apparatus, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed embodiments require that any one or more specific advantages be present or problems be solved.

Claim 1:
A computer-readable storage medium including instructions that, upon execution by one or more computers, cause the one or more computers to implement a protocol selection service (<NUM>) disposed within a service provider environment (<NUM>) to:
provide (<NUM>), to a client computing device (<NUM>) and using a first communication channel (<NUM>, <NUM>) associated with a first communication protocol of a plurality of communication protocols, access to a virtual desktop instance (<NUM>) running on a server computer (<NUM>) also disposed within the service provider environment;
detect (<NUM>) a request for a functionality from a user of the client computing device, the requested functionality unsupported by the first communication protocol;
select (<NUM>), based on the requested functionality, a second communication protocol from a plurality of available communication protocols, the second communication protocol supporting the requested functionality;
verify (<NUM>) whether the user is authorized to use the second communication protocol;
upon successful verification (<NUM>), establish a second communication channel between the server computing device and the client computing device using the second communication protocol; and
switch over at least one of a plurality of functionalities, associated with the access to the virtual desktop instance, to the second communication channel, while providing at least another one of the plurality of functionalities to the client computing device using the first communication channel.