Methods and systems for transferring events including multimedia data

TECHNICAL FIELD

[0001] Embodiments of the present invention relate to computer system networks. More specifically, embodiments of the present invention relate to multimedia streaming in a network environment.

BACKGROUND ART

[0002] Computer system networks provide access to local resources (e.g., software applications, data, Web pages, etc., on a server) from a remote client device. Applications such as virtual network computing have extended this idea further. In a virtual computing network, servers supply not only software applications and data but also a desktop environment that can be accessed and controlled from client devices. In essence, a user at a client device is presented with a display (a graphical user interface or desktop) that is generated at a server and then transferred to and reproduced at the client. Accordingly, the amount of state maintained by the client can be reduced, resulting in what is referred to as “thin” client. Also, a single desktop can be simultaneously accessed and viewed from several different clients. This may be particularly useful when implementing a group of cooperating engineering work stations.

[0003] Prior art virtual network computing systems typically use protocols such as the Remote Frame Buffer (RFB) protocol to provide client access to the server-generated graphical user interface. The image to be displayed on a computer system monitor is held in a frame buffer on the server. In a limiting case, the entire contents of the frame buffer are periodically transferred to the client device for display. Enhancements to the limiting case include sending only the changes to the frame buffer (and hence to the display) that occurred since the preceding transfer.

[0004] Typically, the rate of transfer to the client is about 10-15 frames per second. While this rate is fairly high, it is not considered high enough to satisfactorily transfer video data or multimedia data (video and audio data) from the server to the client. Consequently, prior art systems are limited in this regard.

[0005] Accordingly, a more satisfactory way of transferring video/multimedia data from servers to clients in a virtual network computing system is desirable. Embodiments of the present invention provide such an improvement.

DISCLOSURE OF THE INVENTION

[0006] Embodiments of the present invention pertain to methods and systems for transferring an event from a server to a remote client. An event is received from a driver. The event is dispatched into an event queue according to the event type. The event is processed according to the event type. The processing includes encoding the event when the event comprises multimedia data. The event is transferred to the remote client when triggered. The transfer occurs according to a protocol corresponding to the event type.

BRIEF DESCRIPTION OF THE DRAWINGS

P-0007[0007] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention:

P-0008[0008]FIG. 1 is a block diagram of a server and a client coupled in a network according to one embodiment of the present invention.

P-0009[0009]FIG. 2 is a block diagram of a desktop streaming server in accordance with one embodiment of the present invention.

P-0010[0010]FIG. 3 is a block diagram of a driver interface in accordance with one embodiment of the present invention.

P-0011[0011]FIG. 4 is a block diagram showing differentiation of window updates according to one embodiment of the present invention.

P-0012[0012]FIG. 5 is a block diagram of a desktop streaming engine according to one embodiment of the present invention.

P-0013[0013]FIG. 6 is a block diagram of a desktop streaming client according to one embodiment of the present invention.

P-0014[0014]FIG. 7 is a flowchart of a method for transferring an event to a remote client according to one embodiment of the present invention.

P-0015[0015] The drawings referred to in this description should not be understood as being drawn to scale except if specifically noted.

BEST MODE FOR CARRYING OUT THE INVENTION

P-0016[0016] Reference will now be made in detail to various embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.

P-0017[0017]FIG. 1 is a block diagram of a server <b>101</b> and a client <b>102</b> coupled in a network <b>100</b> according to one embodiment of the present invention. It is appreciated that network <b>100</b> may include elements other than those shown. Network <b>100</b> may also include more than one of the various elements shown; for example, there may be multiple clients coupled to server <b>101</b>, and there may be multiple servers. The functionality of server <b>101</b> and client <b>102</b> is discussed below (refer at least to FIGS. 2 and 6); however, it is appreciated that these elements may implement functionality other than that discussed.

P-0018[0018] Communication may occur directly between server <b>101</b> and client <b>102</b> of FIG. 1, or indirectly through an intermediary device or node (not shown). Also, communication may be wired or wireless, or a combination of wired and wireless. In one embodiment, communication occurs over the World Wide Web (or Internet).

P-0019[0019] In one embodiment, server <b>101</b> and client <b>102</b> are computer systems that provide processing capability and memory capacity. In addition, according to the embodiments of the present invention, server <b>101</b> implements a desktop streaming server <b>110</b>, and client <b>102</b> implements a desktop streaming client <b>120</b>. In this embodiment, desktop streaming server <b>110</b> and desktop streaming client <b>120</b> allow the server <b>101</b> to supply a display (e.g., a graphical user interface, and in particular, a “desktop” display) to the client <b>102</b>. As will be seen, both server-side control and client-side control are allowed, either concurrently or exclusively.

P-0020[0020] According to the embodiments of the present invention, “events” are transferred from server <b>101</b> to client <b>102</b>, and vice versa, using desktop streaming server <b>110</b> and desktop streaming client <b>120</b>, respectively. As used herein, an event is generally an output of a software driver, such as a keyboard driver, a mouse driver, a video driver or an audio driver. Thus, events include detectable actions or occurrences such as clicking a mouse button or pressing a key on a keyboard. Events can also refer to actions or occurrences that can cause a change in the display (graphical user interface) to be displayed by the client <b>102</b>. For example, a change in the display caused by scrolling through a text (word processing) document, or by changing from one page to another page in the document, can constitute an event. A movement of a window in the display can also constitute an event. A moving video display can also constitute an event. An audio sample can also constitute an event.

P-0021[0021] To summarize, as used herein, an event is an output of a driver used with either server <b>101</b> or client <b>102</b>; an event may cause a change in the display on either server <b>101</b> or client <b>102</b>, and/or may cause an audio output at the client <b>102</b>. Events can be generally categorized as: control events, and data events. Control events carry control information to change the execution behaviors of other components, locally or remotely. Data events carry content data to inform other components of content changes.

P-0022[0022] For simplicity of discussion, the term “mouse” is used herein; however, it is understood that other means of cursor control may be used instead of, or in combination with, a mouse. There is a myriad of cursor control mechanisms known in the art, and each of these may be used in accordance with the present invention. The term “keyboard” is also used herein. Again, there is a myriad of mechanisms known in the art that provide the functionality of a keyboard, including voice recognition systems, and each of these may be used in accordance with the present invention. Thus, although embodiments of the present invention are described for a mouse and keyboard, the present invention is not so limited. Instead, the focus should be on the term “event” and how that term is used herein, as described above. In that context, keyboard and mouse events are simply examples of events, while the embodiments of the present invention are well suited to use with virtually all types of events.

P-0023[0023] In one embodiment, on the server side, the events received from the drivers are dispatched into event queues according to the event type. The events are then processed according to their event type; for example, a multimedia event may be encoded. The events are then transferred from server <b>101</b> to client <b>102</b> according to a protocol that corresponds to the event type. In one embodiment, events from keyboard and mouse drivers are transferred to client <b>102</b> using a protocol such as Transmission Control Protocol (TCP), while events from video and audio drivers are transferred to client <b>102</b> using a protocol such as Real Time Protocol (RTP). These processes are described in further detail in conjunction with FIG. 2, below.

P-0024[0024] TCP and RTP are known in the art. TCP provides a highly reliable protocol, while RTP provides the timing capability useful for synchronizing the video and audio portions of a multimedia data object. Thus, TCP can be used to precisely transfer control events (e.g., keyboard and mouse events) as well as other high precision events, such as changes in graphics applications, and RTP can be used for streaming frame buffer (video buffer) and sound buffer updates. Other protocols that can provide these or similar capabilities may be used instead.

P-0025[0025] On the client side, in one embodiment, events are received from keyboard and mouse drivers and transferred to server <b>101</b> of FIG. 1 using a protocol such as TCP. This process is described further in conjunction with FIG. 6, below. In the present embodiment, the relationship between server <b>101</b> and client <b>102</b> does not have the client sending events from audio and video drivers to the server; however, the present invention is not so limited.

P-0026[0026]FIG. 2 is a block diagram of a desktop streaming server <b>110</b> in accordance with one embodiment of the present invention. Desktop streaming server <b>110</b> is implemented in server <b>101</b> of FIG. 1 as hardware, software, firmware, or a combination thereof. As illustrated by FIG. 2, desktop streaming server <b>110</b> includes a number of elements that are rendered separately for clarity of illustration and discussion; however, it is understood that these elements may not exist as separate entities within desktop streaming server <b>110</b>. In general, according to the various embodiments of the present invention, desktop streaming server <b>110</b> provides the capability and functionality provided by the various elements of FIG. 2. In addition, desktop streaming server <b>110</b> may provide other capabilities and functionalities in addition to those described herein.

P-0027[0027] In the present embodiment, a driver interface <b>210</b> receives input (events) from a number of drivers such as, but not limited to, keyboard driver <b>201</b>, mouse driver <b>202</b>, video driver <b>203</b>, and/or audio driver <b>204</b>. Thus, in addition to intercepting more conventional events such as window changes, keyboard input and cursor movement, driver interface <b>210</b> also samples video data from the video driver <b>203</b> and audio data from the audio driver <b>204</b>.

P-0028[0028] Generally, the drivers <b>201</b>-<b>204</b> are components of the underlying operating system. For example, the keyboard driver for a Windows environment may be different than the keyboard driver for a Linux environment. According to the present embodiment, driver interface <b>210</b> provides the capability to communicate with the various types of drivers while providing a fixed interface to the downstream portions of desktop streaming server <b>110</b> (e.g., a fixed interface to event filter <b>220</b>).

P-0029[0029]FIG. 3 is a block diagram of a driver interface <b>210</b> in accordance with one embodiment of the present invention. In this embodiment, driver interface <b>210</b> includes a number of interface modules, exemplified by interfaces <b>301</b> and <b>302</b>, so that there is a module suitable for interfacing with each driver. This is not to say that there is an interface module per driver, although that may be the case.

P-0030[0030] In the present embodiment, driver interface <b>210</b> also includes an application program interface (API) <b>305</b> that is common to the interfaces <b>301</b> and <b>302</b>, etc. The API <b>305</b> provides a single interface to the remainder of desktop streaming server <b>110</b> despite the myriad of possible drivers, and thus insulates the desktop streaming server <b>110</b> from the underlying operating system.

P-0031[0031] Returning to FIG. 2, in the present embodiment, the events from driver interface <b>210</b> are provided to (received by) event filter <b>220</b>. In this embodiment, event filter <b>220</b> identifies the event according to event type, and dispatches the event into a respective event queue according to event type. The event queues are used to buffer similar types of events that can be transferred to the desktop streaming client <b>120</b> (FIG. 1) using a protocol appropriate to the event type (e.g., TCP or RTP) after processing (if any) appropriate to the event type.

P-0032[0032] In the present embodiment, the event filter <b>220</b> of FIG. 2 categorizes events into the following types: 1) control events that are generated by keyboard input or cursor (e.g., mouse) movement, for example; 2) window movement events that are generated by window movements in which window content is unchanged; 3) window updates that are generated by a change in window content; and 4) audio samples that are captured from a change in the sound buffer of the audio driver <b>204</b>. In this embodiment, control events are forwarded to the control event queue <b>231</b>; window movements are forwarded to the window movement queue <b>232</b>; window updates are forwarded to the windows update queue <b>233</b>; and audio samples are forwarded to the audio sample queue <b>234</b>.

P-0033[0033] In the present embodiment, control events in the control event queue <b>231</b> record the coordinate changes of the mouse or cursor. For example, for a particular cursor movement, only the start and end coordinates of the movement may be transferred to the desktop streaming client <b>120</b> of FIG. 1. Control events can be further optimized by the desktop streaming engine <b>250</b>.

P-0034[0034] Continuing with reference to FIG. 2, in the present embodiment, the window movement queue <b>232</b> records the coordinate changes of a window that is being moved (without the content of the window being changed). In those cases in which the window content has been previously transferred to desktop streaming client <b>120</b> of FIG. 1, only the changes in the coordinates of the window may be transferred to the client. The client can then render the desktop display using the previously received window content and the new window coordinates.

P-0035[0035] According to the present embodiment, the window updates queue <b>233</b> of FIG. 2 records the updates of window content. These updates can be captured from the video frame buffer. In one embodiment, in order to facilitate selection of an appropriate encoder and transfer protocol, window updates are categorized into three types: 1) graphics window updates; 2) video window updates; and 3) other window updates. Here, graphics is used to refer to relatively static images (e.g., images having relatively low update rates in comparison to video); video refers to moving images having a relatively high update rate; and other window updates refers to relatively static window content such as the text in a word processing document. Generally speaking, the window updates can be separated into categories according to the complexity of the image and the update frequency.

P-0036[0036]FIG. 4 is a block diagram showing differentiation of window updates according to one embodiment of the present invention. In this embodiment, window updates differentiator <b>410</b> filters the windows into the aforementioned categories. The window updates differentiator <b>410</b> can accomplish this using information such as the display application type, and the coordinates and screen sizes of the windows. The display application type can be acquired from the driver interface <b>210</b> (FIG. 2) when, for example, a new window is created, a Uniform Resource Locator (URL) for a Web site is clicked, or an application is executed. The coordinates and screen sizes help to locate which part of an update to the video frame buffer belongs to which window.

P-0037[0037] Graphics window updates are forwarded to the graphics window updates queue <b>421</b>; video window updates are forwarded to the video window updates queue <b>422</b>; and other window updates are forwarded to the other window updates queue <b>423</b>.

P-0038[0038] Returning to FIG. 2, in the present embodiment, the transfer of events from each of the queues <b>231</b>-<b>234</b> to the desktop streaming engine <b>250</b> is triggered by a respective regulator <b>241</b>, <b>242</b>, <b>243</b> and <b>244</b>. Similarly, in the embodiment of FIG. 4, the queues <b>421</b>-<b>423</b> are under control of a respective regulator <b>431</b>, <b>432</b> and <b>433</b>.

P-0039[0039] In one embodiment, the regulators <b>241</b>-<b>244</b> of FIG. 2 (and the regulators <b>431</b>-<b>433</b> of FIG. 4) trigger (impel) events from their respective queues based on a threshold being reached or a time interval having passed. The threshold is based on the number of events in a respective event queue. When the number of events in the queue reaches a predefined threshold, some portion of the events or all of the events can be transferred from the queue. The threshold mechanism provides the capability to handle a burst of events, in order to prevent the queue from accumulating too many events before the events are transferred in response to a time-out signal. The threshold may be different for each of the queues <b>231</b>-<b>234</b> and <b>421</b>-<b>423</b>. The threshold may also be changed by the desktop streaming engine <b>250</b> based on monitoring of the channels to the desktop streaming client <b>120</b> (FIG. 1), or based on feedback from the desktop streaming client <b>120</b>.

P-0040[0040] Otherwise, according to the present embodiment, the transfer of events from a respective event queue will occur after a specified time interval has passed. Thus, in one embodiment, the regulators <b>241</b>-<b>244</b> of FIG. 2 and the regulators <b>431</b>-<b>433</b> of FIG. 4 can include a timer. The time interval may be different for each of the queues <b>231</b>-<b>234</b> (FIG. 2) and <b>421</b>-<b>423</b> (FIG. 4). The time interval may also be changed by the desktop streaming engine <b>250</b> (FIG. 2) based on monitoring of the channels to the desktop streaming client <b>120</b> (FIG. 1), or based on feedback from the desktop streaming client <b>120</b>. This is described further in conjunction with FIGS. 5 and 6, below.

P-0041[0041]FIG. 5 is a block diagram of a desktop streaming engine <b>250</b> according to one embodiment of the present invention. As illustrated by FIG. 5, desktop streaming engine <b>250</b> includes a number of elements that are rendered separately for clarity of illustration and discussion; however, it is understood that these elements may not exist as separate entities within desktop streaming engine <b>250</b>. In general, according to the various embodiments of the present invention, desktop streaming engine <b>250</b> provides the capability and functionality provided by the various elements of FIG. 5. In addition, desktop streaming engine <b>250</b> may provide other capabilities and functionalities in addition to those described herein.

P-0042[0042] In the present embodiment, scheduler <b>510</b> is coupled to the regulators <b>580</b> (e.g., regulators <b>241</b>-<b>244</b> and <b>431</b>-<b>433</b> of FIGS. 2 and 4, respectively), which in turn are coupled to the queues <b>590</b> (e.g., queues <b>231</b>-<b>234</b> and <b>421</b>-<b>423</b> of FIGS. 2 and 4, respectively). Scheduler <b>510</b> is also coupled to a monitor <b>530</b>. In one embodiment, the monitor <b>530</b> periodically measures the available bandwidth of the channels <b>571</b>, <b>572</b> and <b>573</b>. Although only three channels are shown, it is appreciated that there may be some number of channels other than three. In another embodiment, the monitor <b>530</b> also collects information from desktop streaming client <b>120</b> (FIG. 1) with regard to the workload of the client as well as the attributes of the client device (e.g., the device's display capabilities such as screen size and resolution, the device's processing capabilities such as processor speed, the device's available memory capacity, and the like). Based on the information from monitor <b>530</b>, scheduler <b>510</b> can set or adjust the trigger (e.g., the time interval, threshold or other mechanism) that is used to initiate the transfer of events from the various event queues. As mentioned above, different time intervals, thresholds, or the like can be specified for each of the queues.

P-0043[0043] The schedule for transferring events in the control event queue <b>231</b> and the window movement queue <b>232</b> (FIG. 2) is relatively straightforward because these types of events require less communication overhead and therefore can be transferred almost if not immediately. The schedule for transferring events from the windows update queue <b>233</b> and the audio samples queue <b>234</b> can be adapted according to the information from monitor <b>530</b> (and also from monitor <b>630</b> of the client; see FIG. 6), so as to provide a satisfactory display at client <b>102</b> (FIG. 1).

P-0044[0044] Continuing with reference to FIG. 5, and with reference also to FIGS. 2 and 4, transfer engine <b>540</b> forwards the events from event queues <b>590</b> to the appropriate channel based on the event type. For example, in one embodiment, events from control event queue <b>231</b>, window movement queue <b>232</b>, graphics window updates queue <b>421</b>, and other window updates queue <b>423</b> can be forwarded to a TCP channel, while events from audio samples queue <b>234</b> and video window updates queue <b>422</b> can be forwarded to an RTP channel.

P-0045[0045] With reference to FIG. 5, in the present embodiment, video and/or audio content may be encoded (compressed) using encoder <b>550</b>. The degree of encoding is typically a function of the attributes of the client <b>102</b> (FIG. 1), but the degree of encoding may also be influenced by the bandwidth of the connection (channel) between the client <b>102</b> and the server <b>101</b> (FIG. 1).

P-0046[0046] In the present embodiment, the synchronizer <b>560</b> of FIG. 5 synchronizes the audio with other related media parts. The media parts related to the audio can be text, graphics or video. In one embodiment, the audio and related portions are sent over separate channels (e.g., RTP channels). In that embodiment, synchronizer <b>560</b> requests scheduler <b>510</b> to obtain data from the corresponding samples queue (the audio samples queue <b>234</b>, the window updates queue <b>233</b>, and/or the window movement queue <b>232</b> of FIG. 2) in a synchronized fashion. For example, if one second's worth of audio packets is acquired, one second's worth of video packets should also be acquired. This type of approach helps ensure that the audio and video packets will arrive at the client <b>102</b> (FIG. 1) concurrently or within a short interval of each other. A small buffer may be utilized by client <b>102</b> to overcome any disparity in arrival times.

P-0047[0047] In another embodiment, with reference to FIG. 5, the synchronization is done by encoder <b>550</b>, regardless of whether or not the media parts (e.g, video data) are encoded. In this embodiment, encoder <b>550</b> can multiplex the audio and related media parts, and subsequently transfer the data to communication manager <b>570</b>, which can then transfer the multiplexed packets over one channel (e.g., an RTP channel). A decoder on client <b>102</b> (FIG. 1; also see FIG. 6, below) can play the multiplexed data in a synchronized fashion. For example, within one second of actual time, the decoder can decode one second's worth of audio data, which can be place in an audio buffer. During the time remaining in the one second of actual time, the decoder can decode as many video frames as possible. In this manner, the desktop streaming server <b>110</b> of FIG. 2 is able to take advantage of resources available on the client side.

P-0048[0048] Continuing with reference to FIG. 5, in the present embodiment, communication manager <b>570</b> manages the communication channels <b>571</b>-<b>573</b>. Also in the present embodiment, client event receiver <b>520</b> is for receiving control events (e.g., keyboard and mouse events) from desktop streaming client <b>120</b> (FIG. 1). These events are forwarded by client event receiver <b>520</b> to driver interface <b>210</b> that, in one embodiment, forwards them to video driver <b>203</b> (FIG. 2).

P-0049[0049] In summary, in one embodiment, the desktop streaming server <b>110</b> (FIG. 2) intercepts events from the various drivers, filters those events and dispatches the events to the appropriate event queue based on event type, optionally encodes selected video data and audio data and streams that data to a client over a channel such as an RTP channel, and reacts to events received from the client.

P-0050[0050]FIG. 6 is a block diagram of a desktop streaming client <b>120</b> according to one embodiment of the present invention. As illustrated by FIG. 6, desktop streaming client <b>120</b> includes a number of elements that are rendered separately for clarity of illustration and discussion; however, it is understood that these elements may not exist as separate entities within desktop streaming client <b>120</b>. In general, according to the various embodiments of the present invention, desktop streaming client <b>120</b> provides the capability and functionality provided by the various elements of FIG. 6. In addition, desktop streaming client <b>120</b> may provide other capabilities and functionalities in addition to those described herein.

P-0051[0051] In the present embodiment, desktop streaming client <b>120</b> includes an agent <b>610</b> (which may also be referred to as a daemon). In this embodiment, the agent <b>610</b> establishes and maintains the channel connections with the server <b>101</b>, specifically to the desktop streaming server <b>110</b> (FIG. 1). As mentioned, these channels may utilize the TCP and RTP protocols. Agent <b>610</b> also forwards data received over the channels to processing engine <b>620</b>. Agent <b>610</b> can also respond to inquiries from the desktop streaming server <b>110</b> regarding available channel bandwidth. Furthermore, at the beginning of a session, agent <b>610</b> can inform desktop streaming server <b>110</b> of the client's decoding capabilities as well as other client attributes, such as processor speed, and display screen size and resolution.

P-0052[0052] In the present embodiment, agent <b>610</b> of FIG. 6 is coupled to a monitor <b>630</b>, and can provide information from monitor <b>630</b> to the desktop streaming server <b>110</b> of FIG. 1. In this embodiment, monitor <b>630</b> can monitor the workload of the client <b>102</b> (FIG. 1), and can also provide information regarding available memory capacity. Also, monitor <b>630</b> can provide feedback regarding the efficiency in which the display is generated based on the events received from the desktop streaming server <b>110</b>, so that the streaming rate, for example, can be adjusted accordingly. Thus, for example, the information from monitor <b>630</b> (and also from agent <b>610</b>) can be used by the scheduler <b>510</b> of FIG. 5 to set or adjust the trigger (e.g., the time interval, threshold or other mechanism) that is used to initiate the transfer of events from the various event queues of the desktop streaming server <b>110</b>.

P-0053[0053] With reference to FIG. 6, in the present embodiment, agent <b>610</b> is also coupled to processing engine <b>620</b>. Events received by agent <b>610</b> are forwarded to processing engine <b>620</b>. In one embodiment, processing engine <b>620</b> includes a decoder <b>622</b> for decoding (decompressing) data (events) if the data are encoded. The events from processing engine <b>620</b> are forwarded to driver interface <b>640</b>, which functions in a manner similar to that described above for driver interface <b>210</b> (FIG. 2) to forward the events to video driver <b>663</b> and/or audio driver <b>664</b>.

P-0054[0054] In the present embodiment, driver interface <b>640</b> also receives events from keyboard driver <b>661</b> and mouse driver <b>662</b> of the client device. These events are forwarded to client event processor <b>650</b>, which optimizes these events by eliminating non-critical events and then forwards the critical events to the desktop streaming server <b>110</b> (FIG. 2) via agent <b>610</b>. That is, for example, for a particular cursor movement, client event processor <b>650</b> may eliminate intermediate coordinates associated with the cursor movement, identifying and keeping only the start and end coordinates of the movement for transfer to the desktop streaming server <b>110</b>.

P-0055[0055] Thus, in summary, in one embodiment, the desktop streaming client <b>120</b> (FIG. 6) decodes events transferred from the server (when the events are encoded), updates the display based on the events, provides audio playback when the events include audio samples, responds to inquiries from the desktop streaming server <b>110</b> (FIG. 2), periodically provides monitoring information to the desktop streaming server <b>110</b>, and intercepts control events and sends them to the desktop streaming server <b>110</b>.

P-0056[0056]FIG. 7 is a flowchart <b>700</b> of a method for transferring an event from a server to a client according to one embodiment of the present invention. Although specific steps are disclosed in flowchart <b>700</b>, such steps are exemplary. That is, embodiments of the present invention are well suited to performing various other steps or variations of the steps recited in flowchart <b>700</b>. It is appreciated that the steps in flowchart <b>700</b> may be performed in an order different than presented, and that not all of the steps in flowchart <b>700</b> may be performed. All of, or a portion of, the methods described by flowchart <b>700</b> may be implemented using computer-readable and computer-executable instructions which reside, for example, in computer-usable media of a computer system or like device. Generally, flowchart <b>700</b> is implemented by devices such as server <b>101</b> of FIG. 1.

P-0057[0057] In step <b>710</b> of FIG. 7, in the present embodiment, an event is received from a driver. The event may be a keyboard event, a cursor control (e.g, mouse) event, a video event, or an audio event.

P-0058[0058] In step <b>720</b>, in the present embodiment, the event is dispatched to an event queue according to the event type. That is, events of the same type are forwarded to a particular queue. In one embodiment, the events are filtered to identify event type.

P-0059[0059] In step <b>730</b>, in the present embodiment, the event is processed according to the event type. For example, when the event includes multimedia data (e.g., video data and/or audio data), the event may be encoded. For cursor movement, the coordinates of the points between the start and end points may be eliminated, with only the coordinates of the start and end point retained.

P-0060[0060] In step <b>740</b>, in the present embodiment, the event is transferred to the client when triggered. The transfer to the client occurs according to a protocol that corresponds to the type of event. In one embodiment, event transfer is triggered by the passage of a specified time interval. In another embodiment, event transfer is triggered when the number of events in the event queue reaches a specified threshold.

P-0061[0061] Embodiments of the present invention are thus described. While the present invention has been described in particular embodiments, it should be appreciated that the present invention should not be construed as limited by such embodiments, but rather construed according to the following claims.