U.S. patent application number 13/166003 was filed with the patent office on 2012-12-27 for remote presentation session connectionless oriented channel broker.
This patent application is currently assigned to Microsoft Corporation. Invention is credited to Ravi K. Balachandran, Vikash Bucha, Archan Das, Gopikrishna Kannan.
Application Number | 20120331032 13/166003 |
Document ID | / |
Family ID | 47362852 |
Filed Date | 2012-12-27 |
United States Patent
Application |
20120331032 |
Kind Code |
A1 |
Balachandran; Ravi K. ; et
al. |
December 27, 2012 |
Remote Presentation Session Connectionless Oriented Channel
Broker
Abstract
This document describes a remote presentation infrastructure. In
an exemplary embodiment at least a portion of the data associated
with a remote presentation session can be transported via a
connectionless oriented channel established between a client and a
remote presentation session. In an embodiment, a gateway computer
system can be used to route data to and from a remote presentation
session. In this embodiment, the gateway computer system can be
configured to establish connectionless oriented channels and route
data between remote presentation sessions and clients over
connectionless oriented channels. In addition to the foregoing,
other techniques are described in the claims, the attached
drawings, and the description.
Inventors: |
Balachandran; Ravi K.;
(Hiderabad, IN) ; Das; Archan; (Hiderabad, IN)
; Kannan; Gopikrishna; (Hyderabad, IN) ; Bucha;
Vikash; (Hyderabad, IN) |
Assignee: |
Microsoft Corporation
Redmond
WA
|
Family ID: |
47362852 |
Appl. No.: |
13/166003 |
Filed: |
June 22, 2011 |
Current U.S.
Class: |
709/202 |
Current CPC
Class: |
H04L 9/3247 20130101;
H04L 69/164 20130101; G06F 3/1454 20130101; H04L 67/141 20130101;
G06F 9/452 20180201; H04L 61/6063 20130101; H04L 67/08 20130101;
H04L 67/42 20130101 |
Class at
Publication: |
709/202 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. A computer-readable storage medium including instructions that
upon execution by a processor cause a computer system to: receive a
connection request via a datagram addressed to a public network
address of the computer system, the datagram addressed from a
client network address for a client, the datagram including a
resource network address for a remote presentation session in a
payload; associate the client network address with a private
network address for the computer system and the resource network
address; receive first data for the remote presentation session,
the data addressed to the private network address; and send the
first data via a connectionless oriented channel to the client
network address in response to determining that the private network
address is associated with the client network address.
2. The computer-readable storage medium of claim 1, further
comprising instructions that upon execution cause the computer
system to: determine that second data received via the
connectionless oriented channel from the client is addressed from
the client network address; and send the second data to the
resource network address in response to determining that the client
network address is associated with the private network address.
3. The computer-readable storage medium of claim 1, further
comprising instructions that upon execution cause the computer
system to: receive a second connection request via a second
datagram addressed to the public network address of the gateway,
the second datagram addressed from a second client network address
for a second client, the second datagram including the resource
network address in a payload; and associate the second client
network address with a second private network address for the
computer system and the resource network address.
4. The computer-readable storage medium of claim 1, the first data
being indicative of a graphical user interface from the remote
presentation session.
5. The computer-readable storage medium of claim 1, the first data
being indicative of audio from the remote presentation session.
6. The computer-readable storage medium of claim 1, wherein the
instructions that upon execution cause the computer system to
receive the first data for the remote presentation session further
comprise instructions that upon execution cause the computer system
to: receive the first data from a virtual machine executing on a
virtual desktop server.
7. The computer-readable storage medium of claim 1, wherein the
instructions that upon execution cause the computer system to
receive the first data for the remote presentation session further
comprise instructions that upon execution cause the computer system
to: receive the first data from a remote desktop server.
8. The computer-readable storage medium of claim 1, further
comprising instructions that upon execution cause the computer
system to: associate the client network address with a connection
oriented channel established between the remote presentation
session and the client.
9. A gateway, comprising: a processor; and a memory, the memory
including executable instructions stored thereon that upon
execution cause the gateway server to: extract a package from a
transmission control protocol based packet, the transmission
control protocol based packet addressed from a first internet
protocol address port number combination for a computing device,
the package including an internet protocol address port number
combination for a remote presentation server; establish a
transmission control protocol based channel to the computing device
in response to validating the package; route first data for a
remote presentation session via the transmission control protocol
based channel between the computing device and the remote
presentation server; receive a connection request addressed from a
second internet protocol address port number combination for the
computing device, the connection request addressed to a public
network address of the gateway, the connection request including a
copy of the package; associate the second internet protocol address
port number combination for the computing device with a private
internet protocol address port number combination for the gateway
server and the internet protocol address port number combination
for the remote presentation server; receive a first datagram from
the remote presentation server, the first datagram including data
indicative of a graphical user interface, the first datagram
addressed to the private internet protocol address port number
combination for the gateway; and send the data in a second datagram
to the second internet protocol address port number combination for
the computing device in response to determining that the private
internet protocol address port number combination for the gateway
is associated with the second internet protocol address port number
combination for the computing device.
10. The gateway server of claim 9, wherein the memory further
comprises instructions that upon execution cause the gateway server
to: validate a digital signature stored in the package.
11. The gateway server of claim 9, wherein the memory further
comprises instructions that upon execution cause the gateway server
to: receive a third datagram addressed from the second internet
protocol address port number combination for the computing device
and addressed to a public network address of the gateway, the third
datagram including second data for the remote presentation session;
and send the second data for the remote presentation session in a
fourth datagram to the internet protocol address port number
combination for the remote presentation server, the fourth datagram
addressed from the private internet protocol address port number
combination for the gateway.
12. The gateway server of claim 9, wherein the memory further
comprises instructions that upon execution cause the gateway server
to: receive data indicative of a file from the remote presentation
server; and route the data indicative of the file to the computing
device via the transmission control protocol based channel.
13. The gateway server of claim 9, wherein the memory further
comprises instructions that upon execution cause the gateway server
to: receive user input from the computing device; and send the user
input to the remote presentation server via the transmission
control protocol based channel.
14. The gateway server of claim 9, wherein the memory further
comprises instructions that upon execution cause the gateway server
to: store a connection identifier that associates the second
internet protocol address port number combination for the computing
device with the transmission control protocol based channel.
15. A computer implemented method, comprising: receiving a first
payload from a first datagram associated with a first remote
presentation session, the first datagram addressed to a first
private network address for a gateway; send the first payload in a
second datagram to a first client in response to a determination
that the first private network address for the gateway is
associated with a network address for the first client, the second
datagram addressed from a user datagram protocol port exposed to a
public network; receiving a second payload from a third datagram
associated with a second remote presentation session, the third
datagram addressed to a second private network address for the
gateway; and send the second payload in a fourth datagram to a
second client in response to a determination that the second
private network address for the gateway is associated with a
network address for the second client, the forth datagram addressed
from the user datagram protocol port exposed to the public
network.
16. The computer implemented method of claim 15, further
comprising: validating a cookie obtained from connection request
sent by the first client, the connection request addressed from the
network address for the first client and the cookie including a
network address associated with the first remote presentation
session.
17. The computer implemented method of claim 15, further
comprising: sending data indicative of user input for the first
client to the first remote presentation session via a connection
oriented channel established between the gateway and the first
remote presentation session.
18. The computer implemented method of claim 15, further
comprising: associating the network address for the client with a
connection oriented channel established between the gateway and the
first client.
19. The computer implemented method of claim 15, wherein receiving
the first payload from the first datagram further comprises:
receiving data indicative of a graphical user interface for the
first remote presentation session.
20. The computer implemented method of claim 15, herein receiving
the first payload from the first datagram further comprises:
receiving data indicative of audio for the first remote
presentation session.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] The subject matter described in this document is related to
U.S. patent application Ser. No. ______ entitled "Span Out Load
Balancing Model" (Attorney Docket No. MVIR-0744/332361.01). The
contents of which is herein incorporated by reference in its
entirety.
BACKGROUND
[0002] Resources on a server can be shared with a client computing
device using remote presentation technologies. One exemplary remote
presentation session is called a remote desktop session. In such a
session a desktop is spawned on a server and a communication
channel is established between the server and a client. In this
type of a session the client interacts with the desktop by sending
keyboard strokes and mouse clicks to the server. Images indicative
of the graphical user interface of the desktop are received from
the server and displayed by the client.
[0003] Another type of remote presentation session is called a
remote application session. A remote application session is similar
to a remote desktop session in that user input is sent to the
server; however, a graphical user interface for an application is
sent to the client instead of an entire desktop. As might be
expected, the user is limited to interacting a single application
rather than a desktop in this type of session.
[0004] In addition to the foregoing, another exemplary remote
presentation session is called a virtual desktop session. A virtual
desktop session is similar to a remote desktop session with a few
notable differences. For example, a user does not share an
operating system with other users in a virtual desktop session;
rather, the user has a console session running within a virtual
machine. As such, a virtual desktop session can be thought of as a
personal computer environment that has its graphical user interface
sent to the client.
SUMMARY
[0005] At a high-level of abstraction, this document describes a
remote presentation infrastructure. In an exemplary embodiment, at
least a portion of the data associated with a remote presentation
session can be sent via a connectionless channel established
between a client and server and other data can be transported via a
connection based channel. Accordingly, in an exemplary embodiment,
multiple channels can be used to transport data for a remote
presentation session.
[0006] In an exemplary configuration, a Remote Desktop Gateway
computer system can straddle a firewall that prevents remote
presentation servers from being directly accessed by clients
coupled to a public network, such as the Internet. The Remote
Desktop Gateway computer system can include multiple network
interface cards: one having a public IP address and the other
having a private IP address. Clients can communicate with the
public network interface card and the Remote Desktop Gateway
computer system can communicate with the remote presentation
servers via the private network interface card on behalf of the
clients. In an embodiment, the Remote Desktop Gateway computer
system can include a broker, which can be configured to receive
datagrams and route them to the correct destination. For example,
the broker can receive datagrams from clients and route the data
stored therein to the correct remote presentation server.
Similarly, the broker can receive datagrams from remote
presentation servers and route the data contained therein to the
correct clients. In addition to the foregoing, other techniques are
described in the claims, the attached drawings, and the
description.
[0007] It can be appreciated by one of skill in the art that one or
more various aspects of the disclosure may include but are not
limited to circuitry and/or programming for effecting the
herein-referenced aspects; the circuitry and/or programming can be
virtually any combination of hardware, software, and/or firmware
configured to effect the herein-referenced aspects depending upon
the design choices of the system designer.
[0008] The foregoing is a summary and thus contains, by necessity,
simplifications, generalizations and omissions of detail. Those
skilled in the art will appreciate that the summary is illustrative
only and is not intended to be in any way limiting.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] FIG. 1 depicts a high-level block diagram of a computer
system.
[0010] FIG. 2 depicts a high-level block diagram of an exemplary
architecture for a virtualizing software program.
[0011] FIG. 3 depicts a high-level block diagram of an alternative
architecture for a virtualizing software program.
[0012] FIG. 4 depicts a high-level block diagram of an exemplary
remote desktop server.
[0013] FIG. 5 depicts a high-level block diagram of an exemplary
virtual desktop server.
[0014] FIG. 6 depicts a high-level block diagram of an exemplary
client.
[0015] FIG. 7 depicts a high-level block diagram of an operational
environment for describing broker techniques.
[0016] FIG. 8 depicts a specific example of the data that could be
found in mapping tables.
[0017] FIG. 9 illustrates an operational procedure for establishing
a connection oriented channel and a connectionless channel on a
Remote Desktop Gateway.
[0018] FIG. 10 illustrates an operational procedure for
transporting data via a connectionless channel to a remote
presentation session.
[0019] FIG. 11 illustrates an operational procedure transporting
data via a connectionless channel to a client.
DETAILED DESCRIPTION
[0020] The term circuitry used throughout can include hardware
components such as hardware interrupt controllers, hard drives,
network adaptors, graphics processors, hardware based video/audio
codecs, and the firmware used to operate such hardware. The term
circuitry can also include microprocessors, application specific
integrated circuits, and processors, e.g., an execution unit that
reads and executes instructions, configured by firmware and/or
software. Processor(s) and the like can be configured by
instructions loaded from memory, e.g., RAM, ROM, firmware, and/or
mass storage, and the instructions can embody logic operable to
configure the processor to perform one or more function. A specific
example of circuitry can include a combination of hardware and
software. In this specific example, an implementer may write source
code embodying logic that is subsequently compiled into machine
readable code that can be executed by the processor.
[0021] One skilled in the art can appreciate that the state of the
art has evolved to a point where there is little difference between
functions implemented in hardware and functions implemented in
software (which are subsequently executed by hardware). As such,
the description of functions as being implemented in hardware or
software is merely a design choice. Simply put, since a software
process can be transformed into an equivalent hardware structure
and a hardware structure can itself be transformed into an
equivalent software process, functions described as embodied in
instructions could alternatively be implemented in hardware and
vice versa.
[0022] Referring now to FIG. 1 through FIG. 6, these figures
illustrate suitable exemplary operational environments that can be
used to embody techniques for sending remote presentation session
data via connectionless channels, e.g., via user datagram protocol
("UDP") based datagrams. For ease of understanding, the figures are
organized such that FIG. 1 through FIG. 6 describe exemplary
execution environments, FIG. 7-8 provide further detail, and FIG.
9-11 describe operational procedures.
[0023] Turning now to FIG. 1, it shows an exemplary computer system
100. Computer system 100 can include processor 102, e.g., an
execution core (while one processor 102 is illustrated, in other
embodiments computer system 100 may have multiple processors, e.g.,
multiple execution cores per processor substrate and/or multiple
processor substrates that could each have multiple execution
cores). In addition to processor 102, computer system 100 can
include various computer-readable storage media 110, which can be
interconnected by one or more system buses that couple various
system components to the processor 102. The system buses may be any
of several types of bus structures including a memory bus or memory
controller, a peripheral bus, and a local bus using any of a
variety of bus architectures. In example embodiments the
computer-readable storage media 110 can include for example, random
access memory ("RAM") 104, storage device 106, e.g.,
electromechanical hard drive, solid state hard drive, etc.,
firmware 108, e.g., FLASH RAM or ROM, and removable storage devices
118 such as, for example, CD-ROMs, floppy disks, DVDs, FLASH
drives, external storage devices, etc. It should be appreciated by
those skilled in the art that other types of computer readable
storage media can be used such as magnetic cassettes, flash memory
cards, and/or digital video disks.
[0024] The computer-readable storage media 110 can provide non
volatile and/or volatile storage of processor executable
instructions 122, data structures, program modules and other data
for the computer 100. A basic input/output system (`BIOS") 120,
containing the basic routines that help to transfer information
between elements within the computer system 100, such as during
start up, can be stored in firmware 108. A number of programs may
be stored on firmware 108, storage device 106, RAM 104, and/or
removable storage devices 118. These programs can include an
operating system and/or application programs. In a specific
embodiment, computer-readable storage media 110 of a Remote Desktop
Gateway server can store broker 702, which is described in more
detail in the following paragraphs. In this example embodiment,
broker 702 can be executed by processor 102 thereby transforming
computer system 100 into a computer system configured for a
specific purpose, i.e., a computer system configured according to
techniques described in this document.
[0025] Commands and information may be received by computer 100
through input devices 116, e.g., a keyboard and a mouse. Other
input devices may include a microphone, joystick, game pad, scanner
or the like. These and other input devices are often connected to
processor 102 through a serial port interface that is coupled to
the system bus, but may be connected by other interfaces, such as a
parallel port, game port, or universal serial bus ("USB"). A
display or other type of display device can also be connected to
the system bus via an interface, such as a DVI interface which can
be connected to a graphics processor unit 112. In addition to the
display, computers typically include other peripheral output
devices, such as speakers and printers (not shown). The exemplary
system of FIG. 1 can also include a host adapter, a Small Computer
System Interface ("SCSI") bus, and an external storage device
connected to the SCSI bus.
[0026] Computer system 100 may operate in a networked environment
using logical connections to one or more remote computers, such as
a remote computer. The remote computer may be another computer, a
server, a router, a network PC, a peer device or other common
network node, and typically can include many or all of the elements
described above relative to computer system 100.
[0027] When used in a LAN or WAN networking environment, computer
system 100 can be connected to the LAN or WAN through network
interface card 114. The NIC 114, which may be internal or external,
can be connected to the system bus. In a networked environment,
program modules depicted relative to the computer system 100, or
portions thereof, may be stored in the remote memory storage
device. It will be appreciated that the network connections
described here are exemplary and other means of establishing a
communications link between the computers may be used. Moreover,
while it is envisioned that numerous embodiments of the present
disclosure are particularly well-suited for computerized systems,
nothing in this document is intended to limit the disclosure to
such embodiments.
[0028] Turning to FIG. 2 and FIG. 3, illustrated are exemplary
virtualization platforms that can be used to generate the virtual
machines used to host virtual desktop sessions. In this embodiment,
hypervisor microkernel 202 can be configured to control and
arbitrate access to the hardware of computer system 200. Hypervisor
microkernel 202 can generate execution environments called
partitions such as child partition 1 through child partition N
(where N is an integer greater than 1). Here, a child partition is
the basic unit of isolation supported by hypervisor microkernel
202. Hypervisor microkernel 202 can isolate processes in one
partition from accessing another partition's resources. Each child
partition can be mapped to a set of hardware resources, e.g.,
memory, devices, processor cycles, etc., that is under control of
the hypervisor microkernel 202. In embodiments hypervisor
microkernel 202 can be a stand-alone software product, a part of an
operating system, embedded within firmware of the motherboard,
specialized integrated circuits, or a combination thereof.
[0029] Hypervisor microkernel 202 can enforce partitioning by
restricting a guest operating system's view of the memory in a
physical computer system. When hypervisor microkernel 202
instantiates a virtual machine, it can allocate pages, e.g., fixed
length blocks of memory with starting and ending addresses, of
system physical memory (SPM) to the virtual machine as guest
physical memory (GPM). Here, the guest's restricted view of system
memory is controlled by hypervisor microkernel 202. The term guest
physical memory is a shorthand way of describing a page of memory
from the viewpoint of a virtual machine and the term system
physical memory is shorthand way of describing a page of memory
from the viewpoint of the physical system. Thus, a page of memory
allocated to a virtual machine will have a guest physical address
(the address used by the virtual machine) and a system physical
address (the actual address of the page).
[0030] A guest operating system may virtualize guest physical
memory. Virtual memory is a management technique that allows an
operating system to over commit memory and to give an application
sole access to a contiguous working memory. In a virtualized
environment, a guest operating system can use one or more page
tables to translate virtual addresses, known as virtual guest
addresses into guest physical addresses. In this example, a memory
address may have a guest virtual address, a guest physical address,
and a system physical address.
[0031] In the depicted example, parent partition component, which
can also be also thought of as similar to domain 0 of Xen's open
source hypervisor can include a host 204. Host 204 can be an
operating system (or a set of configuration utilities) and host 204
can be configured to provide resources to guest operating systems
executing in the child partitions 1-N by using virtualization
service providers 228 (VSPs). VSPs 228, which are typically
referred to as back-end drivers in the open source community, can
be used to multiplex the interfaces to the hardware resources by
way of virtualization service clients (VSCs) (typically referred to
as front-end drivers in the open source community or
paravirtualized devices). As shown by the figures, virtualization
service clients execute within the context of guest operating
systems. However, these drivers are different than the rest of the
drivers in the guest in that they may be supplied with a
hypervisor, not with a guest. In an exemplary embodiment the path
used to by virtualization service providers 228 to communicate with
virtualization service clients 216 and 218 can be thought of as the
virtualization path.
[0032] As shown by the figure, emulators 234, e.g., virtualized IDE
devices, virtualized video adaptors, virtualized NICs, etc., can be
configured to run within host 204 and are attached to resources
available to guest operating systems 220 and 222. For example, when
a guest OS touches a memory location mapped to where a register of
a device would be or memory mapped device, hypervisor microkernel
202 can intercept the request and pass the values the guest
attempted to write to an associated emulator. Here, the resources
in this example can be thought of as where a virtual device is
located. The use of emulators in this way can be considered the
emulation path. The emulation path is inefficient compared to the
virtualized path because it requires more CPU resources to emulate
device than it does to pass messages between VSPs and VSCs. For
example, the hundreds of actions on memory mapped to registers
required in order to write a value to disk via the emulation path
may be reduced to a single message passed from a VSC to a VSP in
the virtualization path.
[0033] Each child partition can include one or more virtual
processors (230 and 232) that guest operating systems (220 and 222)
can manage and schedule threads to execute thereon. Generally, the
virtual processors are executable instructions and associated state
information that provide a representation of a physical processor
with a specific architecture. For example, one virtual machine may
have a virtual processor having characteristics of an Intel x86
processor, whereas another virtual processor may have the
characteristics of a PowerPC processor. The virtual processors in
this example can be mapped to processors of the computer system
such that the instructions that effectuate the virtual processors
will be backed by processors. Thus, in an embodiment including
multiple processors, virtual processors can be simultaneously
executed by processors while, for example, other processor execute
hypervisor instructions. The combination of virtual processors and
memory in a partition can be considered a virtual machine.
[0034] Guest operating systems (220 and 222) can be any operating
system such as, for example, operating systems from Microsoft.RTM.,
Apple.RTM., the open source community, etc. The guest operating
systems can include user/kernel modes of operation and can have
kernels that can include schedulers, memory managers, etc.
Generally speaking, kernel mode can include an execution mode in a
processor that grants access to at least privileged processor
instructions. Each guest operating system can have associated file
systems that can have applications stored thereon such as terminal
servers, e-commerce servers, email servers, etc., and the guest
operating systems themselves. The guest operating systems can
schedule threads to execute on the virtual processors and instances
of such applications can be effectuated.
[0035] Referring now to FIG. 3, it depicts similar components to
those illustrated in FIG. 2; however, in this example
configuration, hypervisor 302 can include a microkernel component
and components similar to those in host 204 of FIG. 2 such as the
virtualization service providers 228 and device drivers 224, while
management operating system 304 may contain, for example,
configuration utilities used to configure hypervisor 302. In this
architecture, hypervisor 302 can perform the same or similar
functions as hypervisor microkernel 202 of FIG. 2 and host 204.
Hypervisor 302 of FIG. 3 can be a stand alone software product, a
part of an operating system, embedded within firmware of a
motherboard, and/or a portion of hypervisor 302 can be effectuated
by specialized integrated circuits.
[0036] Referring now to FIG. 4, it illustrates a remote desktop
server 400 that can be used to simultaneously host multiple remote
desktop sessions. Briefly, remote desktop server 400 can include
circuitry configured to effectuate remote desktop sessions for M
clients (where M is also an integer greater than 1). A remote
desktop session can generally include an operational environment
for a user to execute applications that are stored on remote
desktop server 400. In contrast to a computer system running a
console session, e.g., a session where a user is logged into a
computer physically located with the user, each remote desktop
session has limited control of remote desktop server 400. For
example, a user may not be able to change certain configuration
settings, e.g., registry settings, for operating system 414,
install applications, etc.
[0037] As shown in the figure, some components of operating system
414 can be run within the context of a session and others can be
run as system-wide processes. For example, components such as
kernel 420, a file system (not shown), authentication subsystem
424, a scheduler (not shown), resource Broker 404, etc., can be run
as system-wide processes. In operation, some components can be
instantiated on a per-session basis and interact with the
system-wide processes in order to run programs, open/close files,
etc.
[0038] A session can be spawned in response to receipt of a
transmission control protocol ("TCP") Internet protocol ("IP")
connection request by network interface card 412. After receipt of
the request it can be routed to a TCP port that remote presentation
engine 406 is listening on. Next, remote presentation engine 406
can forward connection oriented messages to session manager 408,
which can instantiate a remote desktop session for the connection.
For example, session manager can generate a session identifier; add
the session identifier to a table; assign memory to the session
space; generate system environment variables and instances of
subsystem processes in memory assigned to the session, e.g.,
session manager 408 can start an instance of an operating system
API 410 and remote display driver 418. Session manager 408 can then
cause a logon procedure to start within the session. Meanwhile,
remote presentation engine 406 can instantiate a protocol stack
instance for the session, e.g., stack instance 1, that can send
graphical user interface information for the session to the
connecting client and inject data, e.g., mouse clicks, keyboard
strokes, etc., received from the client into OS API 410.
[0039] In embodiments of the present disclosure, remote desktop
server 400 may also receive a user datagram protocol ("UDP") IP
connection request. Briefly, and described in more detail in
subsequent paragraphs, at least a portion of the data for a remote
presentation session can be transported via a connectionless
oriented channel such as a UDP/IP channel. As such, a UDP/IP
channel needs to be established prior to it being used.
Accordingly, network interface card 412 can receive the UDP/IP
connection request, which can be addressed to a UDP port associated
with resource broker 404 and addressed from a UDP port associated
with a connection object on a Remote Desktop Gateway (which is
described in more detail in subsequent paragraphs). This connection
request can be routed to remote presentation engine 406 and
validated. Next, resource broker 404 can receive a session
identifier from remote presentation engine 406 and store in mapping
table 416 in association with the network address for the
connection object. Subsequent UDP datagrams from this connection
object can be routed to the stack instance associated with this
session, i.e., stack instance 1. Subsequent data that is to be sent
via a connectionless channel can be routed to resource broker 404,
which in turn can send the data in datagrams addressed to the
connection object.
[0040] After a credential, e.g., a username/password combination,
associated with a user is validated, authentication subsystem 424
can generate a system token. This system token can be used whenever
the client attempts to execute a process to determine whether the
client has the security credentials to run the process. For
example, when a process or thread of a session attempts to gain
access, e.g., open, close, delete, and/or modify an object, e.g., a
file, a setting, or an application, the thread or process can be
authenticated by authentication subsystem 424. During an
authentication operation, authentication subsystem 424 can check
the system token against an access control list associated with the
object and determine whether the thread has permission based on a
comparison of information in the system token and the access
control list. If authentication subsystem 424 determines that the
thread is authorized then the thread can be allowed to access the
object.
[0041] Continuing with the description of FIG. 4, in an embodiment
the OS application program interface can include an input subsystem
(not shown). The input subsystem in an example embodiment can be
configured to receive user input from a client via the protocol
stack instance associated with the session and inject the input to
OS API 410. The user input can include signals indicative of
absolute and/or relative mouse movement commands, mouse
coordinates, mouse clicks, keyboard signals, joystick movement
signals, etc. Draw commands can be issued by OS API 410 as well as
applications to an application program interface such as
DirectD3.RTM.. The application program interface can issue commands
to a graphics driver running in kernel space and/or within the
session. A graphics processing unit can generate an image that can
be captured by remote display driver 418, which can send the image
to the stack instance for the session. The stack instance can in
turn send the image to network interface card 412, which can send
the image to the client via an private network or a Remote Desktop
Gateway server, as described in subsequent paragraphs.
[0042] Turning to FIG. 5, it illustrates an exemplary
virtualization desktop server 500 configured to conduct a plurality
of virtual desktop sessions with a plurality of clients (while one
virtual machine is illustrated, virtual desktop server 500 can
simultaneously host many virtual machines). FIG. 5 shows
virtualization system 502, which can be thought of as a high-level
representation of the virtualization platform illustrated by FIG. 2
or FIG. 3. For example, virtualization system 502 can be though of
as representing the elements shown in FIG. 2 such as hypervisor
microkernel 202 and host 204 as well as the components illustrated
as within hypervisor microkernel 202 and host 204. Alternatively,
virtualization system 502 can be thought of as representing the
components depicted as included within of hypervisor 302 and
management OS 304.
[0043] A brief comparison of FIG. 4 to FIG. 5 reveals that the
components used to effectuate remote desktop sessions can be used
to generate virtual desktop sessions. For example, both virtual
desktop server 500 and remote desktop server 400 include remote
presentation engine 406, session manager 408, resource broker 404,
etc. One noticeable difference is that a user conducting a virtual
desktop session has a console session and is the only individual
accessing the guest operating system. As such, the user logged into
guest operating system 506 may be in total control of virtual
machine 504. That is, the user can run as an administrator having
full rights on guest operating system 506 and does not have to
compete with other users logged into guest operating system 506 for
access to resources provided by guest operating system 506. A user
conducting a remote desktop session, on the other hand, does not
have full control of the operating system and interacts with a
customized server version of an operating system. Also, a remote
desktop session deployment involves configuring a server operating
system to allow multiple users to logon to the same operating
system as non-administrators to use its resources.
[0044] Referring now to FIG. 6, it illustrates a high-level block
diagram of a client that can be used to conduct a remote
presentation session with a remote presentation server such as
virtual desktop server 500 or remote desktop server 400. In a
specific example, computing device 602 can be similar to a desktop
computer system, a laptop computer system, a tablet computer
system, a mobile device (such as a cellular phone), etc. As such,
computing device 602 can include some or all of the components that
computer system 100 of FIG. 1 includes.
[0045] In addition to the components illustrated with respect to
FIG. 1, computing device 602 can include remote presentation client
620. In an embodiment, remote presentation client 620 can be an
application stored in memory that can be executed by an operating
system. In another embodiment, remote presentation client 620 can
be a monolithic application that executes without use of a general
purpose operating system. In the former exemplary embodiment, when
a user runs remote presentation client 620 it requests resources
from an operating system. In the latter exemplary embodiment,
remote presentation client 620 may directly control the hardware of
computing device 602.
[0046] Remote presentation client 620 is illustrated as including
multiple subsystems that operate in concert to effectuate the
client-side part of a remote presentation session. Namely, remote
presentation client 620 can include clipboard subsystem 606, device
redirection subsystem 608, display subsystem 618, input capture
subsystem 622, and audio subsystem 624. Remote presentation client
620 may include other subsystems and the disclosure is not limited
to those illustrated by FIG. 6. Briefly, display subsystem 618 can
be used to display images received from the server and audio
subsystem 624 can be configured to receive a stream of audio data
generated by a music player or the like running on the remote
presentation server and output it to speakers attached to computing
device 602. Similarly, clipboard subsystem 606 can be configured to
allow copy and/or cut-and-paste operations to take place between
remote presentation server and computing device 602. For example, a
user could copy a document stored on the desktop of a virtual
desktop server to a desktop of computing device 602.
[0047] In operation, the aforementioned subsystems can use remote
presentation engine 610 to communicate with a remote presentation
server. For example, input capture subsystem 622 can obtain mouse
clicks and keyboard strokes and send them to remote presentation
engine 610, which can encode the data according to protocol such as
the remote desktop protocol ("RDP") into a RDP message that can be
sent it off to the server. Similarly, RDP messages including data
for the remote presentation session, e.g., a graphical user
interface of a word processing program, can be received by remote
presentation engine 610 and decoded. Next, the data can be sent to
the appropriate subsystem, e.g., images can be sent to display
subsystem 618 and a display of computing device 602 can render the
graphical user interface of the remote presentation session.
[0048] Similar to the remote presentation servers described above,
a connection based channel and one or more connectionless channels
can be opened on the client for a remote presentation session. In
an embodiment, each connectionless channel can be associated with
an endpoint object and each endpoint object can be bound to a
different UDP port. For example, and turning to endpoint objects
628 and 630, these objects can be instantiated and configured to
route data in datagrams to and from remote presentation engine 610.
Endpoint object 628 can bind to UDP port 614 and endpoint object
630 can bind to UDP port 628. As such, each UDP connection will
have a different network address. By assigning each connectionless
channel to a different network address data indicative of a remote
presentation session can be allowed to flow to the remote
presentation server through one or more Remote Desktop Gateway
servers.
[0049] Turning back to endpoint objects 628 and 630, remote
presentation engine 610 can maintain a table that maps data from
different subsystems to endpoint objects. For example, remote
presentation engine 610 may include a table that maps display
system 618 to endpoint object 628 and audio subsystem 624 to
endpoint object 630. As such, when data sent via UDP datagrams is
generated by remote presentation engine 610 it can be routed to the
correct endpoint object. Next, the endpoint object can cause a
datagram to be generated that includes the data. The datagram can
be is addressed to a network address of the Remote Desktop Gateway
(or a load balancer) and addressed from the unique network address
for the associated endpoint object. Finally, network interface card
604 can send the datagram to the network address. In a specific
example, suppose that the table maps display system 618 to endpoint
object 628. In this case, if a user generates video, e.g., using a
video capture device or the like, messages can be routed to
endpoint object 628, which can sent them in UDP/IP packets
addressed from the IP address of network interface card 604 and the
port number for UDP port 614 to a network address of a Remote
Desktop Gateway.
[0050] UDP datagrams can also be received by network interface card
604 and routed to the appropriate endpoint object. For example, a
datagram addressed to UDP port 614 or UDP port 626 can be received
by network interface card 604 and routed through the network stack
to the appropriate endpoint object. After receiving a message
stored in the datagram, the endpoint object can route it to remote
presentation engine 610. Next, remote presentation engine 610 can
decode the message and pass the data stored therein to the
appropriate subsystem for processing.
[0051] Turning now to FIG. 7, it illustrates a Remote Desktop
Gateway server (gateway 700) that can be used to allow clients
(computing devices 752-758) coupled to a public network, such as
the Internet, to communicate with one or more remote presentation
servers, e.g., virtual desktop server 736 and/or remote desktop
server 734, which can be connected to a private network. Briefly,
gateway 700 can include components similar to computer system 100
of FIG. 1. As an aside, in a typical deployment, a corporate entity
may control multiple Remote Desktop Gateway computer systems. Each
gateway can be functionally equivalent to gateway 700 and one is
illustrated in FIG. 7 for the sake of simplicity.
[0052] Discussed briefly above, at least a portion of the data for
a remote presentation session can be transported via a
connectionless channel. Generally, an implementer can select any
type of data to be sent via a connectionless channel. However, in
an exemplary embodiment, an implementer may choose to separate data
into data that can tolerate loss and data that cannot and send data
that cannot tolerate loss via TCP based IP packets and data that
can tolerate loss via UDP datagrams. Specific examples of data that
can be sent via a connectionless channel can include data
indicative of audio (music played on a server and streamed to a
client), video (Flash video, HTML 5 video, etc.), images indicative
of a graphical user interface (a bitmap indicative of a desktop),
etc. Specific examples of data that can be sent via a connection
oriented channel can include data indicative of keyboard strokes,
mouse movements, cut-and-paste data, etc.
[0053] One reason for sending at least a part of the data for a
remote presentation session via UDP datagrams is because UDP
traffic can be transported faster than TCP traffic. For example,
UDP based packets are sent without establishing a connection and
dropped packets are not resent. In effect, data is simply packaged
into a UDP datagram; encapsulated in an IP packet; and sent to a
destination IP address/port number combination. The need for
sending data quickly may arise when data that is sensitive to lag
is being transported, such as data indicative of audio, video, etc.
A downside to using UDP datagrams is that there no guarantee that
each datagram will be delivered. As such, lost data is not
retransmitted.
[0054] Turning back to the description of FIG. 7, broker 702 can be
used to configure gateway 700 to handle both TCP and UDP traffic
for a remote presentation session. For example, broker 702 can be
configured to listen on UDP port 730, which can be used by
computing devices 752-758 to send datagrams to gateway 700.
Accordingly, gateway 700 can use a single UDP port to receive
datagrams sent from a plurality of clients. By multiplexing UDP
packets through a single UDP port rather than opening a UDP port on
gateway 700 for each client, the attack surface of gateway 700 is
reduced and the administration costs associated with tracking open
ports is minimized.
[0055] After datagrams are received by broker 702, it can
demultiplex UDP datagrams into separate streams using mapping table
718 and connection objects 710-716. Similar to endpoint objects, an
instance of a connection object can be instantiated for each
connectionless oriented channel established with a client. For
example, FIG. 7 shows connection objects 710-716, each of which may
be associated with a connectionless channel (in the illustrated
example each computing device 752-758 is shown as having one
connectionless channel; however, a client may have one or more
connectionless oriented channels on a Remote Desktop Gateway and
each connectionless channel can be associated with a connection
object). When a UDP based connection request is received by gateway
700, broker 702 can instantiate a connection object and assign it a
socket handle. Once instantiated, a connection object can bind to a
port associated with network interface card 704, i.e., a port on
the private IP network. Briefly, network interface card 704 can be
coupled to a private network and have a private IP address, i.e.,
network interface card 704 can be connected to a network that uses
a private IP address space that is not globally delegated nor can
devices operating on the private IP address space be directly
accessed by a public network such as the Internet. In addition,
each connection object can be instantiated with the IP address/port
number combination for the remote presentation session. As such,
each connection object can include information that enables it to
route data to the appropriate remote presentation session.
[0056] In a specific example, suppose that a UDP based connection
request is received from computing device 752 and the connection
request indicates that computing device 752 is attempting to
connect to remote desktop server 734. In response to receipt of
this request, broker 702 can instantiate connection object 710 with
the network address for remote desktop server 734 and connection
object 710 can bind a private UDP port (e.g., UDP port 744). As
such, connection object 710 can be configured to listen on a
private UDP port for UDP datagrams sent by remote desktop server
734 that are for computing device 752 and send UDP datagrams to the
network address of remote desktop server 734.
[0057] In an embodiment, broker 702 can use mapping table 718 to
determine how to route UDP datagrams from clients to the correct
connection object and vice versa. Turning to FIG. 8, it illustrates
a specific example of the type of information that can be stored in
mapping table 718. As shown by the figure, in an embodiment mapping
table 718 can include a connection identifier for each client. The
connection identifier can be formed directly from a network address
for each client, e.g., an IP address port number combination for
the client and a socket handle for the connection object that is
emulating a connection between gateway 700 and the remote
presentation session. Alternatively, a connection identifier can be
assigned by the gateway as, for example, a unique numerical value
as illustrated in mapping table 718 of FIG. 8. In addition to the
foregoing, mapping table 718 can include information such as the
session identifier, the username/password combination used by
client, the network address for the associated remote presentation
server, etc. Some or all of this information in mapping table 718
can be used to determine where to route data contained in a given
datagram.
[0058] Similarly, resource mapping table 762 can also include a
connection identifier, a Remote Desktop Gateway address, e.g., a
private IP address port number combination, used by an associated
connection object and a session identifier generated by the remote
presentation server. Resource broker 764 and 768 can be similar to
resource broker 760; however, resource broker 764 and 768 may host
a single session since each virtual desktop session runs in its own
virtual machine having its own virtual network interface card. In
the illustrated example, each client is illustrated as having one
UDP channel; however, each client may have multiple channels
established through a Remote Desktop Gateway. As such, mapping
table 718, 762, 766, and/or 770 may have routing information for
multiple connectionless channels that are associated with the same
connection identifier.
[0059] Continuing with the description of FIG. 7, in an embodiment
gateway 700 can use access subsystem 724, remote presentation
gateway client 720, and encryption subsystem 774 to establish a
remote presentation session. In an exemplarily configuration,
access subsystem 724 can determine whether to forward a connection
request to a remote presentation server. As such, access subsystem
724 acts as a first gatekeeper.
[0060] Turning now to FIG. 9 it illustrates an operational
procedure for establishing a connection oriented channel and a
connectionless oriented channel between a client and a remote
presentation server. Operation 900 begins the operational procedure
and operation 902 illustrates that gateway 700 can include
circuitry configured to receive a request for a remote presentation
session from a client. For example and turning to FIG. 7, in a
specific example access subsystem 724, e.g., by executable
instructions run by a processor, can receive a connection request
for a remote presentation session from network interface card
706.
[0061] Suppose that a user operating a client, such as computing
device 752 (which may have components similar to computing device
602) desires a remote presentation session. Here, the user may open
a web-browser and navigate to a webpage associated with the entity
offering remote presentation services that includes a link for
establishing a session. In response to a selection of the link, the
client can send a HTTPS connection request to an IP address TCP
port number combination associated with access subsystem 724. In a
specific example, the IP address can be associated with network
interface card 706 and the port number can be for TCP port 726.
Network interface card 706 of FIG. 7 can receive one or more
packets indicative of a connection request. A network stack can
extract the TCP packet from the IP packet; extract the payload
(i.e., a HTTPS message) from the TCP packet; and route the payload
to access subsystem 724, which could be bound to TCP port 726 in
this example.
[0062] Access subsystem 724 can receive the connection request and
extract a username/password combination from the HTTPS message. The
username/password combination can be authenticated and access
subsystem 724 can allow a properly authenticated connection to
connect to the requested resource. In a typical, remote
presentation session, the requested resource will initially request
a connection to a connection broker 725 or the like. The connection
broker 725, will select a suitable remote desktop server 734 or
virtual desktop server 736 to host the session. For example, if the
request indicates that a remote desktop session or a remote
application session is desired, the connection broker 725 will
search a database that includes IP address port number combinations
for remote desktop servers to find a remote desktop server.
Similarly, if the request is for a virtual desktop session,
connection broker 725 can search a database that includes network
identifiers for virtual desktop servers to find a virtual desktop
server. In a specific example, suppose that the request is for a
remote desktop session and connection broker 725 selects remote
desktop server 734 to host the session. For example, connection
broker 725 can generate a redirection request that causes the
client to send one or more connection requests to one or more IP
address port number combinations for gateway 700 to connect to
remote desktop server 734.
[0063] After establishing the TCP/IP connection with the remote
desktop server 734, in accordance with an aspect of the invention,
it may be desirable to open a second connection with the remote
desktop server 734 in accordance with a particular session
established between the client on computing device 752 and the
remote desktop server 734. As such, a request will be made to the
gateway to open a second connection to the remote desktop server
734. The request can originate from the remote desktop server 734,
the computing device 752, or both.
[0064] In addition to a TCP/IP based connection request, the second
connection request may be for one or more UDP based channels to
gateway 700. In an embodiment, remote presentation client 620 can
be configured to use one connectionless oriented channel to
transport data that can tolerate loss; however, in an alternative
embodiment, remote presentation client 620 can be configured to
open multiple connectionless oriented channels. In a specific
example, remote presentation client 620 can open a connectionless
oriented channel for audio, a connectionless oriented channel for
video, and/or a connectionless oriented channel for a graphical
user interface. Here, endpoint objects can be spawned and each
endpoint object can bind to a port. After successfully binding to
ports, the endpoint objects can send connection requests to gateway
700 via UDP datagrams.
[0065] After the TCP connection is established, access subsystem
724 can generate a package (e.g., a HTML cookie, an XML document,
etc.) that can include configuration information to start a
session. For example, the configuration information can include the
private network address used by remote desktop server 734, a copy
of the username/password combination, a connection identifier, and
a timestamp. This information can be encoded within a package and
then digitally signed by encryption subsystem 774 using a copy of a
key. For example, encryption subsystem 774 can generate a hash of
the data stored in the package and encrypt the hash with an
encryption key. The encrypted hash, i.e., the digital signature,
can be embedded in the package and the package can be
encrypted.
[0066] Next, the encrypted package can be encoded into a response
message and sent by network interface card 706 to the client, e.g.,
computing device 752 in a specific example. Turning to FIG. 6, the
client can include a network stack that can process the IP
packet(s) and extract the response message. The package can then be
routed to connection subsystem 626 and stored in computer-readable
storage medium 110, e.g., the encrypted cookie can be stored in
random access memory 104. Remote presentation client 620 can then
send a connection message to the IP address port number
combinations in the request message.
[0067] Referring to operation 906 of FIG. 9, it indicates that
gateway 700 can include circuitry configured to establish
connection oriented channel to the client. For example and turning
back to FIG. 7, network interface card 706 can receive the
connection request and route it to remote presentation gateway
client 720, which may be configured to listen to TCP port 728.
Remote presentation gateway client 720 in turn can obtain the
connection message and route it to connection manager 722. Next,
connection manager 722 can send the package to encryption subsystem
772, which can decrypt the encrypted package using a key and
validate a digital signature stored in the package. In addition,
connection manager 722 can compute the difference between the
timestamp in the decrypted package and the current time and compare
the difference to a threshold, e.g., 5 minutes.
[0068] In the instance that the digital signature is valid, and the
timestamp difference is less than the threshold, connection manager
722 can validate the package and initiate a connection sequence
between gateway 700 and the client, e.g., computing device 752. For
example, connection manager 722 can generate a socket handle for
the connection and associate it with the connection identifier.
After the TCP/IP connection sequence completes, a message can be
sent back to the client indicating that the connection oriented
channel was established.
[0069] Remote presentation gateway client 720 can route a
connection request to the selected remote presentation server that
can include a copy of the username/password combination for the
user. After the connection sequence between gateway 700 and the
selected remote presentation server is completed, the selected
remote presentation server can validate the username/password
combination; assign the session a session identifier; and start a
session. As an aside, after the TCP/IP channel is opened data can
flow from the selected remote presentation server, e.g., remote
desktop server 734, to the client, e.g., computing device 752. For
example, user input data such as keyboard strokes or mouse movement
coordinates can be encoded into a message by the client and sent
via a TCP/IP channel to gateway 700. Connection manager 722 can
receive the message and route it to remote desktop server 734,
which can inject the user input data into the appropriate session.
Similarly, suppose that a user copies a document from the remote
desktop to computing device 754. In this example, the document can
be sent via one or more TCP/IP packets from remote desktop server
734 to gateway 700 and then routed via one or more TCP/IP packets
to computing device 752.
[0070] Referring briefly to operation 908, it indicates that
gateway 700 can additionally include circuitry configured to
receive datagram from the client, the datagram addressed from a
network address of the client, the datagram including the package.
Turning back to FIG. 7, a connection request can be routed to UDP
port 730 and broker 702, which can be configured to listen to UDP
port 730, can obtain the message. In this example, broker 702
detect the package within the request and route the encrypted
package to connection manager 722. Next, connection manager 722 can
route the package to encryption subsystem 774, which can use its
copy of a key to validate the package. Broker 702 can receive the
package and add the connection identifier to mapping table 718 in
association with the network address of the client, e.g., computing
device 752. At this point, a connectionless channel is established
between gateway 700 and computing device 752.
[0071] Turning briefly to operation 910 of FIG. 9, it indicates
that gateway 700 can additionally include circuitry configured to
instantiate a connection object, the connection object associated
with a network address for the remote presentation server. For
example, broker 702 can instantiate a connection object for the
remote presentation session, e.g., connection object 710 and pass
it the network address for the remote presentation server, e.g.,
remote desktop server 734.
[0072] Operation 912 indicates that gateway 700 can additionally
include circuitry configured to associate a socket handle for the
connection object with the network address for the client. For
example, an operating system running on gateway 700 can generate a
socket handle for the connection object and broker 702 can store it
in association with the connection identifier and the network
address for the client. The connection object, e.g., connection
object 710, can bind to a socket associated with network interface
card 704, i.e., connection object 710 can bind to the IP address of
network interface card 704 and the port number for UDP port
744.
[0073] After receiving a signal indicating that the bind operation
was successful, the connection object can send the connection
request to the remote presentation server. In a specific example,
the connection request can include the username/password
combination provided by the user of the client, a client access
license, configuration settings for the session, i.e., information
that indicates whether device redirection is enabled, and other
configuration settings. A network interface card of remote desktop
server 734 can receive the connection request and route it to a UDP
port that resource broker 404 is bound to. Resource broker 404 can
receive the connection request; detect the connection request; and
forward the payload of the packet, e.g., the remote desktop session
connection request, to remote presentation engine 406. Remote
presentation engine 406 can determine that the payload is similar
to a connection request received via TCP/IP packets and send the
session identifier to resource broker 404. Resource broker 404 can
store the session identifier in association with the network
address used by the connection object. After this set of operations
completes a connectionless channel is established between gateway
700 and remote desktop server 734.
[0074] Turning now to FIG. 10, it shows an operational procedure
that can be executed by gateway 700 in order to transport session
data from a client to a remote presentation server via a
connectionless channel. Operation 1000 begins the operational
procedure and operation 1002 indicates that gateway 700 can include
circuitry configured to receive a datagram addressed from a network
address associated with a client via a connectionless channel. For
example, and referring to FIG. 7, network interface card 706 can
receive one or more UDP datagrams from a client, such as computing
device 758. UDP datagrams can be extracted from the IP packets and
routed to UDP port 730. The payload of the UDP datagrams can then
be detected by broker 702.
[0075] Continuing with the description of FIG. 10, decision point
1004 indicates that gateway 700 can include circuitry configured to
determine if a connectionless channel has been established for the
network address associated with the client. For example, when a
client such as computing device 758 sends a UDP datagram to gateway
700, the packet can include a network address, e.g., the IP
address/port number, that an endpoint object on computing device
758 is using to communicate with gateway 700. The payload of the
datagram can be routed to broker 702, which determine whether the
packet includes a connection request. If not, broker 702 can use
the network address associated with the endpoint to determine the
socket handle for the connection object handling datagrams from
this client. In a specific example and referring to FIG. 8, broker
702 can determine that mapping table 718 includes an entry mapping
the network address for computing device 758 to connection object
716. If the datagram includes a connection request broker 702 can
route the payload of the datagram to connection manager 722 as
described above.
[0076] Turning to operation 1006, it shows that gateway 700 can
include circuitry configured to send the payload of the datagram to
a connection object that is associated with a remote presentation
session. Referring to FIG. 7, in a specific example where the
datagram is from computing device 758, it can be routed to
connection object 716.
[0077] Turning to operation 1008, it shows that in an embodiment
gateway 700 can also include circuitry configured to send a
datagram to a network address associated with the remote
presentation session, the datagram addressed from a network address
associated with the connection object. For example and again
referring to FIG. 7, the connection object, e.g., connection object
716, can send a request to a network stack to send the payload in a
UDP datagram to the network address for the remote presentation
session, e.g., virtual machine 740 in a specific example. In this
specific example, connection object 716 may be bound to UDP port
750. As such, the UDP datagram sent by network interface card 704
can include the private IP address of network interface card 704
and the port number for UDP port 750 in a source address field and
an private IP address and a UDP port number associated with
resource broker 768 running in virtual machine 740 in a destination
address field.
[0078] Suppose that virtual machine 740 is running on a computer
system similar to virtual desktop server 500 of FIG. 5. In this
example, network interface card 412 can receive the UDP datagram
addressed from the private IP address of network interface card 704
and the port number for UDP port 750 and it can be routed through
virtualization system 502 to resource broker 768. Resource broker
768 can parse the source address field and determine that the UDP
based packet was received from connection object 716. As shown in
FIG. 8, resource broker 768 can look in mapping table 770 and
determine that the payload is for the virtual desktop session and
route it to an instance of remote presentation engine running
within virtual machine 740.
[0079] Turning now to FIG. 11, it illustrates an operational
procedure that can be used to route a payload via a connectionless
channel between a remote presentation server to a client. Operation
1100 begins the operational procedure and operation 1102 indicates
that gateway 700 can include circuitry for receiving a first
datagram addressed to a network address for a connection object,
the datagram including a payload. For example, and turning to FIG.
7, network interface card 704 can receive a UDP datagram from a
remote presentation server such as remote desktop server 734. When
a UDP datagram addressed to the IP address for network interface
card 704 and the port number for UDP port 744 is received it can be
routed to connection object 712. In this example, remote desktop
server 734 could have previously received a UDP datagram that was
addressed from connection object 712 and resource broker 760 may
have stored the network address for connection object 712 in
mapping table 762.
[0080] In a specific example, suppose remote desktop server 734 is
effectuating a remote desktop session for computing device 754. In
this example, remote desktop server 734 can encode data indicative
of a graphical user interface, e.g., an image of a desktop, video,
e.g., HTML 5 video embedded within a webpage, audio, e.g., a song
being played on remote desktop server 734, etc., into a remote
desktop message. Next, the message could be sent to resource broker
760 along with a session identifier. Resource broker 760 can use
mapping table 762 to determine the network address for gateway 700,
i.e., the network address associated with connection object 712,
and cause a UDP datagram including the remote desktop message to be
sent to the determined network address.
[0081] Turning back to FIG. 11, operation 1106 indicates that
gateway 700 can include circuitry configured to determine that a
socket handle for the connection object is associated with a
network address for a client. Referring to FIG. 7, connection
object 712 can send a signal to broker 702 indicating that a remote
desktop message was received. Broker 702 can obtain the payload and
use the socket handle for connection object 712 to search mapping
table 718. Turning briefly to FIG. 8, here, broker 702 can
determine that the socket handle for connection object 712 is
associated with network address for computing device 754.
Accordingly, broker 702 can send a send request to a network
protocol stack to send the payload to the network address for
computing device 754. The network stack can generate a UDP datagram
having the network address of gateway 700, e.g., the IP address of
network interface card 706 and the port number for UDP port 730,
set as the source address and the network address of computing
device 754 set as the destination address.
[0082] Turning to FIG. 6, suppose that computing device 754
includes components that are similar to computing device 602. As
such, network interface card 604 of computing device 754 can
receive the UDP datagram and extract the remote desktop protocol
message stored therein. The message can be routed to remote
presentation engine 610, which can process the payload and send it
to the appropriate end point. For example, display subsystem 618 in
the instance that the payload is indicative of an image or
video.
[0083] The foregoing detailed description has set forth various
embodiments of the systems and/or processes via examples and/or
operational diagrams. Insofar as such block diagrams, and/or
examples contain one or more functions and/or operations, it will
be understood by those within the art that each function and/or
operation within such block diagrams, or examples can be
implemented, individually and/or collectively, by a wide range of
hardware, software, firmware, or virtually any combination
thereof.
[0084] While particular aspects of the present subject matter
described herein have been shown and described, it will be apparent
to those skilled in the art that, based upon the teachings herein,
changes and modifications may be made without departing from the
subject matter described herein and its broader aspects and,
therefore, the appended claims are to encompass within their scope
all such changes and modifications as are within the true spirit
and scope of the subject matter described herein.
* * * * *