Citrix acquires Framehawk, one of our favorite companies. Here's our full analysis.

Today, Citrix announced their acquisition of Framehawk, a company known in part for their home-grown protocol called LFP (Lightweight Framebuffer Protocol) that has been created from the ground up to work on high-latency, inconsistent networks.

Today, Citrix announced their acquisition of Framehawk, a company known in part for their home-grown protocol called LFP (Lightweight Framebuffer Protocol) that has been created from the ground up to work on high-latency, inconsistent networks; not to mention their exceptional client interface and management capabilities. There are a few angles that can explain Citrix’s interest in Framehawk, and I want to take a look at each of them. We should know more about their plans and the rationale behind the acquisition in the coming days/weeks, but there’s more than enough to contemplate now.

The key feature of Framehawk is the ability to “iPad-ify” Windows applications (and Linux, too) so they are more useable on iPads than they would otherwise be using more conventional remote desktop solutions, protocols, and clients. The fact that Framehawk bolts on to your existing environment means that you don’t have to change your infrastructure to use it. (I suppose that convenience also applies to acquisitions!) An admin can publish an application to users, which sounds like the same old story, but what’s compelling is that the platform can tweak the end user experience not just per application, but per region on the screen. It supports gestures, offset mouse, and some of the other more common features, but it does this in customizable way. It even has features akin to those in Parallels Access, like text field detection, which pops up a context-specific keyboard (think full keyboard in Word, internet keyboard in IE URL box, etc…).

I sometimes look at this as the antithesis of the Citrix Mobility SDK. To iPad-ify mobile applications using it, you need to actually modify code on your homegrown apps. That’s all well and good if you own the app and have the developers, but refactoring an app for use on a different form factor is tough work with a lot of requirements (like having access to your app’s code). Framehawk’s method sits in between the app and the end user, restructuring things as needed for any application. (Note: I've also heard that you do need an SDK to fully customize the interface for Framehawk. So now it's 1-1. If you know something, feel free to comment)

Framehawk has two deployment methods: from the cloud or from the datacenter. Both are identical in terms of what they do, it’s just that with the cloud method you don’t have to roll your own infrastructure. It means that in the future world where Windows is nothing more than middleware, you simply have to connect Framehawk to the app and deploy...easy as that. In a way, it’s like Mainframe2 that Brian covered recently.

Is this what Citrix is focused on with the acquisition? iPad-ifying applications and making it easier to deploy Windows apps to non-Windows mobile devices? Surely that’s part of it, they could have done some of this themselves. Don’t forget about the protocol.

I’ve had a soft spot for Framehawk since the middle of last year after I first got a demo of the product. In fact, I’m slightly jealous of Brian and Jack since they live in San Francisco and the TechTarget office there is about a block away from Framehawk’s, so they’ve seen some killer demos. I’ve speculated about their potential for acquisition, going so far as to say that if VMware and Teradici part ways, Framehawk would be a good fit for them. Frankly, I never even considered Citrix as an option, mostly because they are so joined to the hip of ICA/HDX.

Still, it makes sense. HDX has a long history in the desktop virtualization world, going back long before we actually called it desktop virtualization. It was invented in the 1990s to address a use case that, while it still exists today, is vastly different from what it was back then. Since then, it has been adapted and expanded to accommodate new workloads and use cases. As with anything so old and universally used, Citrix is forced to maintain some level of backwards-compatibility, and as such the underlying architecture of the protocol over the years hasn’t changed all that much. Any improvements in performance are largely done by adding features on top of the protocol, not changing the protocol itself.

When Mobility became a thing, Citrix did what they could to HDX to make it as mobile-friendly as possible, and they did a good job with what they had. It wasn’t until Framehawk arrived on the scene that we saw exactly how good things could be. I’m guessing Citrix has realized that, and if they want to be in the business of delivering Windows apps to mobile devices into the future, decided they needed to do something.

So how will this all fit into Citrix? What will they do with in the short term / long term? Part of the advantage of the bolt-on solution is that they don’t have to do much in order to get the technology on-boarded. I’d imagine we’ll see a Find & Replace version of Framehawk (XenHawk?) with Citrix branding fairly soon, probably even before Synergy. Eventually, as the technology from the client gets folded into Receiver, I see this as an add-on component for NetScaler, although I’m not sure how much we need in the way of resources to support users. It could be a standalone encoder, for instance, while NetScaler handles the provisioning and access.

The LFP protocol is central to the mobile side, but HDX performs just fine inside the company walls. I don’t think we’ll see HDX go away in the next few years. It could even be possible that the two protocols can be used in conjunction with one another, should an internal use case become apparent. Still, while the mobile use case is certainly there, I don’t think you’re going to see an LFP-TCP listener any time soon, but you can expect to see the Framehawk technology incorporated alongside HDX.

So, look for an expanded Windows on mobile message from Citrix in the coming months, as well as a lot about how HDX can now perform better in harsher environments. Derek Thorslund already posted a blog about this, although how and when Framehawk and HDX will be merged remains to be seen. In the not-too-distant future, we’ll probably start to see more about delivering Windows apps in a more simple fashion, a la Mainframe2.

Of course, Citrix could have purchased Framehawk for the simple reason of keeping them away from competitors (something which is often alleged when discussing Kaviza). That would protect any advantage they have in the protocol wars. I'm an optimist, so I hope they use the features that they purchased even if that was the primary reason, but I guess we'll see. This, combined what what VMware is up to, is making for a pretty exciting January! Stay tuned for more information on the acquisition, and if you want to learn more about Framehawk, check out this primer.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

and the possibility that Citrix acquire them to avoid competitor's acquisition and protect their advantage in remote display protocol space ?


That's definitely an option, and I am aware of other companies talking to Framehawk in recent months (not necessarily about acquisition, but of partnering). I should put that in the article, actually. Thanks for bringing it up.


Derek's blog would indicate that the primary motivation for this acquisition was for the LFP protocol. Citrix found themselves as the only major player without a host-rendered protocol based on UDP. Acquiring LFP will begin to close that gap and validates the approach Teradici has been pursuing for almost 10 years. However, LFP was not designed to support silicon-based zero clients nor hardware accelerated protocol offload on the server, so it only addresses one part of the competitive gaps that ICA/HDX has today.

I want to congratulate Stephen and the team for this significant accomplishment, but do need to point out that Gunnar's demo video does not represent anything close to the real problems with wireless networks. Sure, the 50% packet loss is way too extreme, but the bigger issue is that demos use random packet loss. Wireless networks typically have a very low levels of random packet loss. The bulk of the packet loss is usually in long bursts of lost packets due to RF interference, Access Point hand-offs, etc... where the error recovery mechanisms in LFP are not nearly as effective. So, while LFP will help close a major gap in the current Citrix display protocol offerings, this does not imply that LFP has any significant advantage over the PCoIP protocol (or any well-designed UDP protocol) over real wireless networks especially with the new bandwidth management algorithms already being tested at VMware and Amazon for release shortly. Customers need to test any protocol over real networks rather than simulated networks unless they are very careful about how they set up the simulations.


@randy and what will PCoIP do to address all the TCP based stuff that HDX does that you don't?


@appdetective  Many HDX features exist to get around the limitations of being a client-rendered, TCP-based display protocol. Thus, the PCoIP protocol does not need to implement those features (including not needing a Netscaler).

Many other HDX features only work on Windows or Linux clients (or worse, only on Windows clients plus a browser and a Flash plug-in). Customers dislike features that only work on Windows clients because they don't want to double the number of Windows images they have to manage when they move to VDI/DaaS. Furthermore, with the popularity of BYOD and the proliferation of mobile and zero clients, most devices that are connecting to a VDI/DaaS desktop are not Windows or Linux devices anymore. Thus, an OS agnostic solution to customer requirements is critically important. This is certainly one of the reasons Citrix is playing catch-up by acquiring the LFP protocol.

The key is being able to solve real customer issues, not matching HDX directly feature for feature. As an example, Tesla provides a very different set of solutions to their customers than their gasoline-powered competitors. Likewise, the PCoIP protocol uses different approaches than HDX, because it has always been a host-rendered, UDP-based display protocol designed for any type of client.


Great discussion!  Regarding an earlier point, I agree that protocols need to be evaluated in the wild, not just wan simulations.  LFP has characteristics to handle swings from 0% to 90%+ seamlessly, and was designed for goofy mobile networks.  But we also weren't saddled with any legacy environments and could focus on that type of problem.

I think it's awesome that Amazon has entered the DaaS marketplace with PCoIP. While the business model has challenges with the Fortune 1000 who are not yet comfortable with public cloud VPN to corporate data sources (it was a motivator for us to develop an on-premise appliance for the bigger companies), it absolutely brings focus to the market and validates the marketplace especially across SMB.

I am thrilled that we can be technically evaluated against such an established veteran like Randy and his team.  And now combined with the scale reach of Citrix and integrated into the venerable HDX, I am excited to help do our part to increase market adoption of apps, desktops and mobile experiences.  Competition is a good thing.  It creates better products for customers...