From the Blogosphere
Is HTML5 the Answer to Mobile's VDI Challenge?
Thin is back in
By: Lori MacVittie
Oct. 17, 2012 08:00 AM
Remote display and control technology is nothing new. For decades we've had the ability to remotely access and control our desktops using a variety of technologies and protocols: X11, VNC, RDP, and Terminal Services to name a few of the more well-known.
Remote display and control has been used for a variety of purposes not the least of which is the IT administrator's need to remotely root around on your desktop to troubleshoot an issue.
VDI is not the same as remote display and control, though many neophytes might understand it that way. VDI in general requires some form of client application; a client application that currently does not exist for every possible end-user client computing device. Thus VDI is not universally supported on mobile devices, despite a (apparent) desire by end-users for just such capabilities.
The choices for vendors of VDI technology are support an ever-increasing array of devices (and operating system versions) or find a device/operating system agnostic technology with which to deliver the desktop experience on a mobile device. Zero-client technology, as many are wont to describe it as. It's really reinventing remote display and control with technology better suited to unmanaged, widely variable endpoints using near-ubiquitous protocols, like HTML.
Hidden among the new features and functions for VMware Workstation 9 is one such "new" wheel: WSX.
WSX is a web server, a proxy, enabling access to your virtual desktop (provided its running on vSphere/ESXi 5). Clients communicate via WebSockets (HTTP) and the display is rendered via HTML5 graphic elements.
VMware clearly indicates this is a prototype, and lists a number of caveats regarding current limitations, but given that similar technology (Web Sockets and HTML5) is used elsewhere in production VMware solutions it seems clear that this early entry into the zero-client VDI game will continue to evolve and mature into a production-ready solution.
But what about …
Good questions, and ones for which there are currently no good answers. The use of WebSockets as a transport medium for what is essentially proprietary protocols crossing domain boundaries is problematic. While access control can ostensibly be handled by existing solutions providing secure remote access today (WebSockets is, after all, initiated via HTTP which has a variety of means by which authentication and authorization can be enforced) integrity of the data may be an issue as well as the potential for exploitation of the web server providing the proxied WSX service as intermediate devices would not be able to parse let alone recognize anomalies in the actual data exchange.
Scalability would be constrained to layer 4 (TCP) due to the lack of meaningful (and open) data at layer 7 (application) upon which intermediaries could manage flows and sessions. Persistence to an existing WSX server would necessarily revert to decades old techniques such as IP/Port combinations that have long since proven to be problematic, particularly as such schemes tend to result in unpredictably uneven load distribution.
There are a variety of issues raised by the use of WebSockets across networking domains in general, and as a means to enable remote display and control these issues are no different. The advantages, of course, lie in the ability to define a protocol specific to the application (in this case VDI "light") and use a single, long-lived asynchronous control layer that has significant benefits in terms of performance.
If the trend toward leveraging HTML5 and in particular WebSockets continues, then WebSockets will likely turn out to be one of the more disruptive technologies on the networking market since … well, since HTTP.
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week