Citrix XenDesktop's HDX and VMware View's PCoIP offer the same basic functionality -- providing video, sound, and peripheral support to remote desktop users -- but they each use a different transport protocol, HDX riding TCP and PCoIP riding UDP. Most end-users won't be interested in the TCP-versus-UDP debate, but network admins will always have an opinion, especially if their responsibilities include network monitoring, WAN optimization, or VPN support.
There are some fundamental differences between TCP and UDP traffic. TCP provides a reliable method of sending packets across the network. Each packet is numbered and must arrive at the other end in the same order as transmitted. If a packet fails to reach its destination, the recipient will alert the sender and the missing packet will be retransmitted. TCP is used when the application -- such as a Web app, a file transfer, or email -- requires the packets to arrive in the correct order.
[ Also on InfoWorld: "VDI shoot-out: Citrix XenDesktop vs. VMware View" | Download InfoWorld's Virtual Desktop Infrastructure Deep Dive special report | See which solution came out on top in InfoWorld's "Virtualization shoot-out: Citrix, Microsoft, Red Hat, and VMware" ]
UDP is not quite so structured. It sends datagrams without any form of error checking or end-to-end handshaking. This means that UDP packets may arrive at the destination out of order or go missing without the sender being alerted to the problem. UDP is used mostly for streaming content such as VoIP, online video broadcasts, and online games. In these apps, the loss of a few packets means only a slight degradation in the audio or video quality -- hardly a showstopper. UDP introduces less overhead than TCP, and there is less latency associated with it, allowing it to transfer large amounts of data quickly.
From the network administration standpoint, TCP is a much more manageable protocol, and every network monitoring tool and appliance can work with it. By contrast, UDP is not well supported by some network tools, particularly WAN optimization appliances and VPN tunnels. In order for UDP to pass through a VPN tunnel (to remotely access a virtual desktop, for example), it has to be wrapped by TCP. This of course increases the network overhead and negates the performance advantage UDP has over TCP.
An important consideration for the IT staff planning a large VDI rollout (i.e., thousands of virtual desktops) is that, because UDP traffic doesn't lend itself to traffic shaping, there is the risk of saturating the WAN link. Without forethought and careful planning, large numbers of users connecting into View over PCoIP could choke the link into submission. An alternative would be to use Microsoft's TCP-based RDP (which View supports) to deliver virtual desktops to external users, but then you give up the benefits inherent in PCoIP.
Both HDX and PCoIP provide an excellent way of sending lots of data -– video, audio, interactive –- over a constrained WAN link. Both help mitigate a certain degree of latency, and even in low-bandwidth situations they can make remote users feel as if they are connected to the LAN. But HDX and PCoIP are not able to overcome a slow WAN link. For Windows 7 Aero-enabled desktops, a fast WAN or LAN link will be required.
The remote desktop protocol is not the only consideration when choosing a VDI solution, but it is something that network admins will have to keep in mind during the initial planning stages. The adoption of PCoIP could increase the cost of deployment if essential network services that don't handle UDP well have to be upgraded. Will the end-user be able to tell a difference between TCP-based HDX and UDP-based PCoIP? Probably not. Both handle their duties well and provide the end-user with the remote experience they expect. Just add this to the long check list of items for the network admin.
This article, "VDI shoot-out: HDX vs. PCoIP," was originally published at InfoWorld.com. Follow the latest developments in virtualization at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.