For the past few releases of both XenApp and XenDesktop, I’ve been working on the HDX MediaStream Flash Redirection feature.  The basic purpose of the feature has remained the same: render Flash content (especially Flash-delivered videos) on the client device rather than on the server in order to give the end-user a better experience and improve server scalability and bandwidth consumption.  However the feature has seen some significant rework for the currently emerging releases (XenDesktop 5.5 and XenApp 6.5 for W2K8R2), so it’s a good time to present what’s new and what’s different with HDX Flash.

There are too many tweaks and minor improvements to exhaustively list here, but a few feature changes worth focusing on:

  1. Support for the NPAPI Flash Player on the client device, which enables the HDX Flash for Linux implementation and the possibility for implementations on other client platforms
  2. Improved performance over the WAN
  3. More flexible configuration

I’ll discuss each change listed above in a bit more detail.

Support for the NPAPI Flash Player and Non-Windows Client Platforms

Earlier releases of HDX Flash were completely devoted to Internet Explorer and Windows.  Specifically, they required the ActiveX Flash Player on the client device to help render the Flash content.  This design precluded any support for non-Windows client platforms since the ActiveX Flash Player is Windows-only.

For XenDesktop 5.5 and XenApp 6.5, HDX Flash no longer uses the ActiveX Flash Player on the client; it uses the NPAPI Flash Player on the client.  This means implementing HDX Flash for other client platforms is now within the realm of possibility – supporting HDX features on a wider variety of clients is becoming more of a focus within Citrix engineering.

One drawback with switching from the ActiveX Flash Player to the NPAPI Flash Player is that the ActiveX Flash Player is more common on Windows client platforms (though the NPAPI Flash Player is functionally equivalent and fully supported from Adobe).  When you download the Flash Player from via your browser, Adobe defaults you to ActiveX if you are using IE, and defaults you to NPAPI otherwise.  It’s easy to override this by clicking on a link:

 Adobe Flash Player download page

But the fact is, if an end-user only uses IE on the Windows client device they probably won’t have the NPAPI Flash Player installed.  In the worst case we’ll just gracefully revert to server-side Flash rendering so this isn’t a disaster, but it would prevent the deployment from using the HDX Flash feature.  In managed environments we recommend that the administrator push out the NPAPI Flash Player to their Windows client devices.  But even in the case where the NPAPI Flash Player hasn’t been preinstalled on the client device, we try to improve things by prompting the end-user to install it (if and when they browse to Flash content within their XenApp/XenDesktop session):

 Dialog prompting the end-user to download the NPAPI Flash Player

Improved Performance over the WAN

HDX Flash has always had very light bandwidth requirements between the Receiver and the XenApp/XenDesktop server (assuming the Flash content is fetched directly by the client, which is the default).  However, prior to XenDesktop 5.5 and XenApp 6.5, HDX Flash didn’t perform well over connections with higher latencies.  The system detected the latency on the connection, and if was higher than 30ms round-trip server-side rendering was used.  No harm done, but the benefits of client-side Flash rendering – user experience, scalability, and bandwidth limitations – were lost.

For XenDesktop 5.5 and XenApp 6.5, we improved the HDX Flash protocol so that it is much less chatty.  This makes the system much more tolerant of latency.  Once the Flash app or video is playing on the client, there is typically little or no interaction necessary between the client and the server, so the latency of that connection is irrelevant.  One of the strengths of Citrix products, features and protocols has always been WAN performance, so now the HDX Flash feature is in line with that standard. 

Support for “Whitelist” Configuration

HDX Flash renders Flash content in an “unnatural” way – outside of the browser running on the XenApp/XenDesktop server.  This arrangement works in general but there will always be certain websites and Flash content that don’t work correctly under HDX Flash.  It’s our job to minimize this set and we’ve made good progress on that front, however 100% compatibility with all present and future content is not realistic.

In previous versions, we offered a mitigation whereby the XA/XD administrator could disable HDX Flash for specific websites (identified by full or partial URL like http://**) by configuring a Policy.  This was effective for the case where the feature was to be generally enabled, except for a few problematic sites.

For XenDesktop 5.5 and XenApp 6.5, we’ve made this HDX Flash Policy more flexible: now it is a list of URL patterns each of which can specify either to use client-side rendering (use HDX Flash), to use server-side rendering (don’t use HDX Flash), or to completely block the Flash content.   The list is ordered so an entry can be refined by a subsequent more specific entry.  This all means that an administrator can disable the feature generally and selectively enable it for certain Flash content.  The following screenshot gives an idea of what this configuration might look like:

Policy to configure HDX Flash for specific URLs

Customer-driven Improvements

The advantage of working on the second version of a feature is that there is a lot of real-world feedback from customers – both end users and administrators – about the previous version.  We took advantage of this for HDX Flash in XenDesktop 5.5 and XenApp 6.5 and made a ton of additions, improvements, and tweaks in response.

I won’t try to list all these improvements here, but just give an example.  We had a specific customer that was using the feature and generally happy with it.  However they found that when using HDX Flash, some of their Flash-delivered videos were spending a lot of time buffering – the Flash Player was only able to fetch the video content (.flv file) very slowly.  We troubleshot this with the customer and found that they were using a Content Delivery Network (CDN) to deliver the Flash video.  This was causing a problem because the customer’s server was geographically remote from their client.  The CDN was serving the video to HDX Flash on the client based on the geographic location of the server.  So, the Flash Player on the client was fetching the .flv file from a remote content server, leading to poor performance.

We worked with the customer on how we could handle this arrangement in HDX Flash, and came up with a new policy that causes the Flash Player to “reset” its geographic location when requesting content from the CDN, so that its true geographic location can be determined and the content served efficiently.  Everyone went home happy.