Well, I thought it would be nice to discuss the attributes and features of VMware View4 new PCoIP protocol which will be released shortly. In case you don’t PCoIP stands for PC over IP – and then intention is to deliver remote display protocol which rivals “legacy” thin-client protocols such as RDP/ICA with a new protocol that offers a “PC-like” experience over the wire. Historically, protocols like RDP/ICA have not performed well in graphics intensive applications like scanning, CAD, and streaming video.
If you want to see what PCoIP looks like to the end-user – prior to the GA some folks have put videos up on youtube.com. Of course, the quality of those videos vary – how ironic!
VMware’s main competitor in this will be Citrix XenDesktop’s HDX protocol. It’s been a long time in the gestation. VMware has been talking about PCoIP for some time, and its been an on-going project with Teradici which historically has specialized in hardware and software based remote display delivery. VMware View4 delivers a software experience, but the co-development will allow smart terminal manufacturers to fit graphics cards that leverage hardware based graphics acceleration.
Since View3.1, VMware has endeavored to support other protocols such Sun’s Appliance Link Protocol (ALP), and HP’s Remote Graphics Software (RGS). Additionally, by supporting RDP – they pushed out the envelope beyond supporting only virtual machines, but access to Blade PC and Terminal Services as well. VMware wants to continue supporting these other protocols – but the hope is over time that folks will favour PCoIP.
First things first – some practical things. There is no “special” client or agent for PCoIP that has to be installed and configured – PCoIP is built-in to both the View Agent (installed to the VM) and the View Client (installed to the Windows PC – it’s an optional component). Incidentally, you mist install the FULL View Client (not just use the View web-pages) to get the PCoIP driver installed to the client device. Installing the agent installs special audio and graphics drivers (codecs) into the virtual desktop. You would expect that with all this capacity for graphically rich user experience that PCoIP would be undesirable on the WAN. However, according to PCoIP it can degrade the user experience to compensate for increase in latency or narrow-bandwidth.
It’s perhaps with that sentence that I should issue disclaimer. After this point much that I’m going write is based on me reading documentation. I wasn’t allowed on to the View4 beta programme. In fact a great many of peers (other vExperts) weren’t on the View4 Beta Programme. I’ve been told that many of the FTSE 100 companies – weren’t on the beta programme either. In fact its been one of the most elusive beta programmes that VMware has run in recent years. So its VERY difficult at this stage to really properly benchmark these claims for performance. The other thing I would say, is even if this FUD turns out to be groundless – there maybe other reasons to with this implementation of PCoIP that might make it a “LAN” based technology rather than a “WAN” or more properly speaking a “Internet Protocol”. I dare say there will be a lot of FUD around the PCoIP protocol, and in fairness VMware will only have themselves to blame – after making access to the beta programme so exclusive. With that said, beta code is notorious for being unsuitable for true bench tests – it still has debug symbols included in it – with GA code doesn’t. Anyway, according to VMware – even if your WAN link displays 150ms-250ms latency – PCoIP will still deliver satisfactory performance. As I write this – I’m sitting in a hotel in Bergen, Norway – pinging my equipment in Nottingham, UK. The latency is 55ms via the hotel Wifi link. Latency is often seen as the be all, end all when it comes to remote desktop displays – in my experience the frequency of dropped and retransmitted packets are as important. The maximum my latency has been (while I was typing this article) was 452ms and I lost 3% of the packets during that time.
Anyway, before I go further let's have a look at the features of PCoIP – and explain how it manages to achieve it's magic. PCoIP gets most of acceleration from special codecs which process the graphical data to the users screen – the clever bit is that PCoIP can identify different graphical components – and then render that portion the sceen with the correct codec. So if you think about the screen – that screen will built with many graphical components such as icons, video, text, photos and the kind of graphics that you might see in PowerPoint or Excel Charts. PCoIP has a codec for each type, and can get an idea of the types of screen content and then render with the right codec.
Another critical feature is “progressive build”. PCoIP races to get the information to the user screen as quickly as possible – in a lossy format. Typically, a web-page will show text, first and basic image. Then quickly and in the background these images get progressively sharper and better quality. This is particularly good for rapid web-browsing (where the user goes backwards and forwards rapidly) because the user will not be waiting for images to be built slowly – in a line by line - pixel by pixel basis – like RDP does.
Putting aside these core components there are some other PCoIP features which you should be aware of:
- Multi-monitor Support (4 displays of the same resolution)
- 32-bit colour
- 1920×1200 Resolution
- Clipboard functionality (Cut & Paste Text to/from local device to PCoIP Session)
- Control Bandwidth allocated to media formats like Flash (think youtube.com!). This is done by the View Agent installing a special control into the web-browser – so the system is aware it is running inside a virtual desktop. It then uses the VMware Adobe Flash Optimizer to control the bandwidth for different “Flash” experiences such as youtube.com or interactive flash demonstrations
- USB is supported
- Multimedia redirection is supported if the device supports (this is where video is played locally using local graphics/audio control – and redirected away from the ICA/RDP/PCoIP session
So far – wonderful stuff. OK, well I guess it time of the downsides – because they always are. In View3, VMware acquired a license for “ThinPrint” which they dubbed “Virtual Printing”. It’s a not full implementation of the ThinPrint product incidentally. Virtual Printing and PCoIP are incompatible. This means unless you procure a solution that IS compatible – you will be forced to use native printer drivers – which eat up precious bandwidth. In fact, printing has been the bane of everyone’s life who operates in the thin-client arena. I speak as someone who started with NT4 and Citrix MetaFrame 1.8 and finished with Citrix Presentation Server 4.5 PCoIP must be currently used with “Direct Connection” to the View Connection Server. Currently, PCoIP is incompatible with VMware Views “Security Server”. In case you don’t know. Connection Servers sit on your private network, and are joined to domain. As such you should never put them in a DMZ because they are vulnerable. Security Servers on the other hand are designed to facilitate firewall traversal – and are suitable for the DMZ. If you unfamiliar with the relationships my buddy, Tom Howarth who has real world experience of VMware View implementations has this handy diagram:
This is quite important limitation. It means any existing View implementation that uses a combination of Connection & Security Servers – cannot be used with PCoIP. It means introducing a different access mechanism - such VPN connection to make the PCoIP protocol secured with SSL and ”firewall friendly”. Those of you have been this business for while will now that although this limitation isn’t a show-stopper as such – it’s a stumbling block. Historically, users haven’t like VPN clients. They can be arse to setup and get working. And most users who rarely appreciate the distinction between the [SHIFT] key and the [SPACEBAR] rarely appreciate the reason why the VPN session must be brought up first before they can do any work. Certainly, most Citrix and View end-users are used to cranking up client or web-browser – typing in their username/password – and getting their desktop. PCoIP will work with 128-bit SSL, but again its unclear what the performance overhead might be with that additional payload. You might be interested to know why a PCoIP session can connect to Connection Server, but not Security Server. It’s quite simple. PCoIP sessions are established with UDP packets (Port 50002 to be precise) to the Connection Server – and Security Servers only support TCP sessions. Whilst the PCoIP protocol does have built-in encryption – its not clear at this stage how this SSL session established. From what I tell it is NOT certificates based, but generated by internal algorithm. This is very similar the kind SecureICA that existed in the early Citrix MetaFrame product – prior to the introduction of certificates based encryption with things like the Citrix Secure Gateway and the Citrix Access Gateway. It’s fair to say that the competition (Citrix) has in the past introduced feature such as “Session Reliability” which have in the 1st instance been incompatible with their Security Systems. So to some degree ALL the thin-providers are guilty of this: “Here’s brand new feature that massive improves performance and the user-experience – Oh, and by the way its incompatible with all our firewall traversal products…” The good news is View4 is configurable in such way – that you could allow the user to select PCoIP if they were on the corporate LAN, and use thinner-more firewall friendly protocol when they are on the WAN/Internet. Whether they appreciate the difference is any one’s guess! By default the preferred protocol is PCoIP unless changed by the administrator or the end-user in the client.
On the audio side – PCoIP does support high quality audio OUTPUT, but it currently lacks an audio INPUT. This means such devices as voice-recorders – popular say in hospitals where doctors/consultants like to “record” their notes would have be delivered some alternative method.
So. There we have it the good, the bad and the ugly. Certainly our industry has been crying out for replacements for RDP/ICA for some years – and both Citrix and VMware have put some good R&D into the new protocols. Clearly, PCoIP is work in progress – and there’s much that can be done in the world virtual desktop to improve the manageability such as good deployment tools – and the flexible ways of delivering the apps to the virtual desktop. Additionally, there are still specific weakness in the world of printing and bolting down the desktop – where old methods such as Microsoft GPOs simply don’t cut the mustard. There are interesting days ahead!