Technical analysis of the Wyse Zero platform and Wyse Xenith HDX zero client

The Wyse Zero client device

As I wrote yesterday, Wyse Zero clients share a hardware platform with current Wyse C class clients (which can be ThinOS, WinCE, Windows XPe, WES, or Linux). Check out Wyse’s PDF spec sheet for more details on the C class, or read our article about them when they were released last year.

One of the things about Wyse Zero that I didn’t like initially was that customers can’t “convert” an existing C class thin client into a Wyse Xenith or a Wyse Zero client. “That’s crazy!” I thought, “it’s the same hardware!?!” While this is true, it occurred to me a few days later that this is already the case for just about any thin client. For example, a customer can’t convert a WinCE C class into an embedded Linux C class, so why would the Wyse Zero be any different? (Of course this doesn’t explain why this is the case, but I’m just pointing out that it’s not new with Wyse Zero.) It's probably possible from a technical standpoint, because the the Wyse Xenith at Synergy had a masking tape sticker on the bottom with the word “converted” written in pen. :)

Regardless, choosing to leverage the C class platform for the Wyse Zero products is a great move on Wyse’s part. The C class is Wyse’s most advanced yet lowest-powered device. It has a dedicated media decoder chip, WiFi, and a super-tight package.

Wyse Zero architecture

As I touched on yesterday, there are a few moving parts in the Wyse Zero / Wyse Xenith architecture, including:

• The client device, with some bare-bones capabilities (Wyse claims this isn’t firmware, so whatever... it’s something) that can get a DHCP address to read the URL of the engine it should download.
• A web server containing the protocol “engine” the device should download which provides the core functionality
• (optional) A central configuration file on the web server which controls settings for the clients like key rate, language, mouse tracking speed, etc. These settings can also be controlled in the client by editing the... what? Nonfirmware?

So the boot process of the Wyse Xenith looks like this:

1. Client powers on.
2. Client requests an IP address via DHCP.
3. Client requests DHCP option tag 161 (location of the central config INI file) and then 181 (location of XenDesktop)
4. Client checks to see if there is an updated version of the Xenith HDX engine (officially called "Citrix Receiver for Wyse Xenith) or any additional central configuration present (via FTP/HTTP/HTTPS) and updates itself accordingly.
5. User sees the XenDesktop login screen.

A few notes on this process:

The Xenith checks for DHCP option 161 first because it's possible that an admin chooses to not setup option tag 181 but to instead put the address of the XenDesktop Web Interface as part of config file which is delivered via the location specified in 161.

If you don't have the ability to configure any DHCP options (locked down DHCP or maybe for home users) then you can hard-code the central config file URL in the firmware of the device. (Although the device will still try to read DHCP flag 161 first in case you ever want to change your mind later.)

Finally, the HDX engine and config file location doesn’t have to be on the Citrix Web Interface Server. That’s just the default that Wyse suggests since customers will already have it up and running. (And by the way, the “installation” on the web server is just creating a folder called “wyse” and copying some files in. Future versions of Citrix Web Interface will actually even have this built-in.)

How much "HDX" does the Xenith support?

In the video from yesterday, Jeff referred to the Xenith as a “real” HDX client, pointing out that you don’t need a host-side agent or special driver or anything to connect to your XenDesktop environment. But nowadays the term “HDX” means so much more than just the old core ICA protocol. I asked Wyse for clarification on which exact HDX features are supported on the Wyse Xenith device, and here’s what they told me (most of this was demoed in the video):

• HDX Plug-n-Play: USB 2.0, printing, true multi-monitor, smartcard, isochronous USB 2.0 (webcam, etc.)
• HDX RealTime: VOIP on LAN, client audio recording
• HDX Mediastream: CD quality audio on LAN
• HDX Mediastream (via client-rendered multimedia redirection): WMV, H.264, DIVX, MS-MPEG4
• HDX Mediastream (via host-rendering): Flash, Quicktime, and everything else.
• HDX WAN Optimization (Branch Repeater, etc)
• HDX Broadcast (Session Reliability, etc)
• Other: Access Gateway (in CSG mode), Progressive Display, desktop restart, auto-connect, ICA ping, etc

This is certainly an impressive list, and I don’t want my following comments to suggest that I’m not happy with it. However, it’s important to point out that the HDX that the Wyse Xenith supports is not 100% identical to the HDX you get with the full Win32 Citrix Receiver stack. Specifically the Wyse Xenith doesn’t support as many types of multimedia redirection (i.e. client-side rendering) as the Win32 Receiver.

The big thing that most people will probably miss is Flash redirection. With Win32 HDX Receivers and the latest version of XenDesktop or XenApp, you can get Flash redirection where the Flash content will be redirected from the remote host and rendered on the client device. With Wyse Xenith, all Flash rendering happens on the remote host and is sent to the client just like any ordinary remote graphical objects.

Of course it’s understandable why Wyse is taking this approach. HDX Flash redirection requires a Flash client on the client device, and I can’t imagine that Wyse wanted to pollute their Xenith HDX engine with Flash decoding garbage. (And I’m sure they had much more access to the HDX Receiver code from Citrix than they would from Adobe for a Flash client.)

If you want to know which media types will be processed on the client and which will be host-rendered, just take a look at the spec sheet for the VIA VX855 media chip that Wyse builds into the C class devices. According to VIA’s website, “The VIA Chromotion™ video engine delivers ... advanced video acceleration for H.264, MPEG-2, MPEG-4, and WMV9 video formats.” It's safe to assume that the Wyse Xenith's local media decoding capabilities for HDX MediaStream align with what the VIA chip can do.

While we’re on the topic of media processing it’s worth sharing another funny anecdote: At Synergy last week one of VMware’s competitive folks was complaining about Wyse Xenith marketing claiming that “Xenith isn’t even full HDX because it doesn’t do client-side Flash redirection.” Very true. However, this is the same VMware employee who often talks about how good PC-over-IP is because it doesn’t require client Flash components to do Flash. So by VMware's logic, Flash on Wyse Xenith should be better than Flash via normal HDX because the Xenith approach is philosophically more like PC-over-IP. But this VMware guy is claiming that Wyse's HDX Flash claims are actually misleading because they're not inline with how people expect HDX Flash to work (which is worse than PC-over-IP)!

Regardless of your perspective, Wyse realized that Flash is important and host-rendered Flash performance over HDX is not always good. At Synergy last week we learned that Wyse worked with Citrix to “optimize” Flash for the Xenith. But what exactly does that mean? I asked and received this answer:

Since Wyse Xenith is a zero client, embedding the Adobe Flash player and all the framework required around it was not possible without compromising the key security and simplicity attributes we aimed to achieve with a zero client. We know most enterprise users view flash videos and animation in their native resolution (i.e. not full-screen) and with Wyse Xenith we are able to provide a smooth video and animation with audio synchronization without requiring native flash components. This significant improvement was achieved in conjunction with the Citrix HDX team by optimizing the internal algorithms used to decode the visual plane as well as dynamically prioritizing the audio versus video channels to provide smooth movement and audio synchronization even with heavy flash content. Citrix also has details in their knowledge base on how the server-rendered flash experience can be improved further for customers with challenging environments.

Don’t forget XenApp!

In the comments of yesterday's Xenith overview article someone asked whether Wyse Xenith could also be used with XenApp. I checked with Wyse, and as long as you’re connecting to XenApp published desktops, then yes, the Xenith will work fine. Same Citrix Web Interface, same HDX, same central config, etc. The main caveat they pointed out was that Xenith is designed to connect to a full desktop, so there's no support for seamless apps on the client or anything. (If you want to publish seamless apps directly to clients then you’d want to use a more traditional thin client.) But in terms of connecting to desktops, either XenApp or XenDesktop are fine.

Pricing

Wyse Xenith devices will start at USD $329, or $379 with WiFi b/g/n. Standard volume discounts will apply.