by Jo Harder, CTP, Tampa CUGC Leader, CUGC Women in Tech Founding Mentor
If you just look at the two XenApp/XenDesktop policies associated with Framehawk, you might think this technology was no big deal. After all, how complex could it be if all you have to do was enable Framehawk and select the port range?
Of course, Framehawk falls under HDX, which is one of the key differentiators between XenApp/XenDesktop and its competitors. The good news is that Framehawk isn’t complex from a user or administrator standpoint, but the technology behind it is just plain fantastic.
Let me explain how this works …
The ICA protocol functions on Layer 6, Presentation Layer, of the OSI model. ICA is divided into virtual channels, such as Thinwire, Client Drive Mapping, Printing, Clipboard, Mouse, and more. XenApp/XenDesktop 7.6 FP2 introduced a new virtual channel, Framehawk.
By default, Thinwire is used for display remoting, i.e., screen graphics. Thinwire is great but where there is significant packet loss, such as with wireless and 3G/4G networks in particular, users get frustrated when they click or scroll and nothing happens. So, what does the user do? He or she clicks or scrolls repeatedly thinking that the server didn’t accept the user action. Meanwhile, Session Reliabilty has stored all those clicks or scrolls, and when the network is restored, the user sees several rapid activities and output or a location that was unexpected.
Framehawk, on the other hand, is based on UDP and has extensive intuition built in: the Intent Engine. The Intent Engine isn’t binary like Thinwire but instead distinguishes user actions and communicates the focus area on the screen to the VDA. The technology behind Framehawk includes a time-based heat map so it senses the active area of the screen. Extending the example from above, Framehawk doesn’t transmit those extra clicks or scrolls where packet loss exists because those packets intelligently fall into a black hole. So, if there is ongoing packet loss from an unstable network, the user experience will be improved.
Framehawk is recommended when packet loss exceeds 3%. It will use extra resources on the VDA, particularly CPU, so you’ll need to account for that. The good news on that front is that the upcoming XenApp/XenDesktop 7.8 release in late Q1 will incorporate better scalability.
When implementing Framehawk, you’ll need to configure the NetScaler Gateway 11.0-62.10 or higher as well. After all, Framehawk is fine for your internal wireless users, but the major use case is probably your mobile users.
When Framehawk was released with XenApp/XenDesktop 7.6 FP2, it was a somewhat fragmented release because you had to get multiple components from multiple places. Now that XenApp/XenDesktop 7.7 has been released, all the components are in one place, so if you plan to implement Framehawk now, it is best to do so based on v7.7.
