A deeper look at Ericom's "AccessNow" HTML5 client. Why wait for Citrix & VMware?

Gabe wrote about how HTML5 clients work almost a year ago, and he mentioned Ericom's HTML5 client in his review of his Chromebook. Put simply, Ericom AccessNow is an HTML5 client for using remote desktops through web browsers.

Gabe wrote about how HTML5 clients work almost a year ago, and he mentioned Ericom's HTML5 client in his review of his Chromebook. Put simply, Ericom AccessNow is an HTML5 client for using remote desktops through web browsers. The client is "installed" on a web server (which can be Windows or Linux), and then end users just visit a web page and BOOM--they're accessing a remote desktop or application via the web. It doesn't require anything on the client--no plug-in, no download, no extension--just an HTML5 browser (which is every desktop browser now, plus iOS, Android, Blackberry, etc. Basically everything.)

Ericom accessnow

One of the great things about AccessNow is that it's available today. In addition to building a standalone generic RDP version that can connect directly to Terminal Servers or Windows desktops, Ericom has also built capabilities to integrate with Quest vWorkspace and VMware View. So if you want to instantly "browser enable" either of those platforms, you can do it with Ericom. (In fact Ericom recently announced that Richland School District Two bought 30,000 AccessNow licenses for VMware View environment.)

You might think that VMware would be mad about this since they themselves are working on an HTML-based View client codenamed "AppBlast." Well maybe the AppBlast product manager is upset about Richland Schools buying Ericom for access to View, but I can guarantee you that the local VMware sales rep has no problem with it at all. If Ericom enables this school to use View, hey.. go for it!

Quest Software has taken the same approach, saying essentially, "Hey, the Ericom AccessNow client is great. If they want to build that and sell it to our customers to give them HTML access, great! That's one less thing we have to worry about and frees us up to build other features."

So both VMware and Quest are happy with it. The only one missing is Citrix. I asked Ericom's CEO Eran Heyman why they didn't integrate AccessNow with Citrix XenDesktop and XenApp, and he said, "Hey, we've approached them many times, but they've refused to work with us. So it's there loss I guess?" Meanwhile Citrix customers are stuck in the dark ages while Quest and VMware VDI customers get clientless browser-based access to their desktops. Oh well. Hopefully some day Citrix will release their HTML5 client.

The world of browser clients is a world of 6-week release cycles

One thing that became clear when speaking to Ericom about their HTML5 client was that the world of browser access clients is very different than the world of traditional RDP and VDI clients.

First of all, many browsers have moved to a very fast 6-week release cycle. This means that capabilities that were flat-out impossible one day could be in beta a month later and released to millions of users a month after that. And as new capabilities move into the browser mainstream, users are going to expect that their web access clients support these new features too.

In Ericom's case, they released the beta version of their HTML5 client last May, then the initial v1 in July, then minor updates which added new features in September and November. And they're looking for another update this quarter with many more to follow this year. And actually there's an advantage that a small company has. Both Citrix and VMware announced that they were working on HTML-based clients last year, but neither has managed to get even v1 out there yet. Of course they try to claim, "well of course Ericom can do this because they don't have the huge userbase that we have, but we as a huge enterprise company can't be so willy-nilly about releases." Well fine, but Google manages to release new versions of Chrome every six weeks to their 200+ million users, so this is just Citrix and VMware pouting.

And sometimes these new browsers can enable significant new features. For example, a recent new version of Chrome contained a new audio API which enabled Ericom to add support for client-side microphone redirection. So now that users can use their mics with other sites, Ericom had to react quickly to build that support into their HTML client. It's not like the old days when they can have that feature in the next version which comes out a year later.

HTML5 web browser "sandbox" limitations

In addition to the client-side audio support mentioned above, you can imagine that building a pure HTML-based VDI client with a decent feature set can become frustrating quickly. Even "simple" things like having a button to make the thing go full screen are complicated thanks to unscrupulous spammy websites of the nineties.

But Ericom is taking it all in stride, attacking the features one at a time the best they can while working within the boundaries of the browser. Want client device drive mapping? A big no-no in the web world, Ericom's workaround is to use a file transfer mechanism that's invoked by simply dragging and dropping the file you want to upload onto the page.

Printing will be handled in a new version via a host-side PDF print generation engine that then downloads the finished doc to the client.

"Real" USB access? Well, there's always the native client for that. :)

The current version of AccessNow is also missing some key features around gestures, (though those are being added in the upcoming version.) Ericom is kind of limited in a lot of ways because they're fighting with the browsers a bit. The browsers try to had the "actual" frame geometries form the remote website. So things like the zoom levels, pixel size, etc.--that's all hidden. So to get around that, Ericom's HTML on the client forces it to a ratio of 1:1.

Gestures are also very complex. It's hard to figure out when a user is swiping a gesture that should be remoted to the remote desktop or if the user is wanting to use the gesture to invoke some local action on the client. The good news is that new browsers are adding gesture APIs. (And on top of that, browsers are adding API support for tilt, location, etc.)

Native clients versus HTML clients

In many ways, the Ericom AccessNow HTML5 is different than device-native clients. (The "native" client being the Win32 app on Windows, an iOS app on iPads, a Mac application on a Mac, etc.)

The downside to the native client is that they have to be installed and they have to be written for the specific client platform. The upside is they have raw access to the hardware and they're written in whatever high-performace language the developer feels like using. And that's a key point. It's tempting to think that the future will be only HTML5 apps, but in reality HTML5 VDI clients will never have the performance or features of native clients.

A good example of this is the way that Ericom integrated their "Blaze" technology into their AccessNow HTML5 client.

If you're not familiar with Blaze, it's essentially an extension which speeds up RDP on low-bandwidth and high-latency networks. To create Blaze, Ericom licensed the RDP protocol spec from Microsoft so they can really tear into it. And tear into it they do. Blaze has a host-side component and a client-side component. On the host the look inside the RDP protocol not just for doing compression or acceleration, but they actually decrypt and decompress the entire stream on the host side before it's sent to the client. That gives them the raw RDP data which they then analyze and rebuild. The consolidate frames, compress images, identify text, etc. Sometimes they simply compress images here and there. Other times they rebuild the entire frames. Overall they understand the connection characteristics and what they're looking at in the RDP frame, so they can make intelligent decisions. This allows them to work smarter than optimization which is happening only at the network level after the RDP data has already been created.

Blaze is great and people love it. So when it came time to build their AccessNow HTML5 client, people asked them, "Hey, does this use Blaze?" And the answer is no. AccessNow is not Blaze at all. Then people ask, "Will AccessNow ever work with Blaze?" And again, the answer is no.

The reason is that with Blaze, Ericom controls the client. So they can have "real" access to a high performing environment with precise control over their software engine. But with the AccessNow HTML5 client, the only client access they have is Javascript and whatever APIs the browser maker enabled. So if they just "ported" their existing Blaze client to HTML5 Javascript (which is interpreted as opposed to compiled), it would be slooooooooowwwww. Not good.

Now this is not to say that Ericom didn't incorporate any of the techniques of Blaze into AccessNow. In fact they took everything they learned with Blaze and tried to build as much as they could into AccessNow. (Identifying full frames in videos to avoid tearing, dealing with latency and reshaping packets, etc.) And of course they'll leverage native browser API functions whenever they can. But to be clear, AccessNow is not Blaze. It's not the same source code. It's more like a fork that's appropriate for a weak client that can has to run everything in Javascript.

In a sense you can almost view the HTML5 clients running Javascript in the same way that you view PCoIP zero clients. With zero clients, all the hard work is done on the remote host so you can have a super weak, super thin client. Because Javascript is so slow (relative to compiled code) in browsers, that's essentially what you have. A native Blaze client is more like a real RDP client where the client is doing a lot of heavy lifting. And just like running RDP on a PCoIP zero client provides a horribly slow experience, the same would be true if they tried to do Blaze in a browser.

"Feature dependent," not "browser dependent"

Speaking of APIs and browsers, one of the realities that Ericom quickly realized is that not all browsers are the same when it comes to running HTML5 applications. Sure, there's a base standard that all the browser makers are striving towards, but that's an ideal world fantasy. (Though Ericom did say that given that all these browsers are developed by different companies in different parts of the world, the HTML5 standardization is actually pretty good.)

But the devil is in the details. Different browsers on different platforms have different APIs and support different features. This means that the Ericom AccessNow HTML5 client could actually have different features depending on which browser is used.

Ericom realized early on that trying to keep track of which features were supported on which browsers was a fool's errand. So they designed AccessNow to be "feature dependent" rather than "browser dependent." What that means is that rather than saying, "Ok, I see this browser is Chrome 14, so it supports X, Y, and Z features, but not A and B…" Rather than that, their client uses Javascript to systematically test for each capability. So when the session is starting, they can, for example, test for the client-side audio support by making an API call. If it works, great, they'll support that capability in that session. If not, no problem--they just won't use that feature. Doing this means that if some random browser vendor on some random platform suddenly enables support for a new API, the Ericom AccessNow client can instantly take advantage of it, even if no one at Ericom knew about it.

A practical example of this is whether the communication from the remote host to the HTML5 browser uses HTTP or WebSockets. (For example, IE9 and the Android native browser both support HTML5 but don't support WebSockets.) Using WebSockets is ideal for Ericom and provides a better experience for the user. You could imagine a world where Ericom would just test for the browser version and say, "Oh you support WebSockets" and then turn it on. Unfortunately there are many scenarios where the browser itself might support WebSockets, but where an intermediate firewall or VPN might not. So if Ericom simply tested for the browser version, then they'd have a connection fail because some intermediary didn't support what they needed.

Practical use for Ericom AccessNow

It's easy to see where Ericom AccessNow can be used. It's a great fallback client for unknown or unmanaged devices. It's also a great way to "web enable" existing old-school Windows apps. You could even imagine having a page (or a single frame) of some larger web portal that was an AccessNow connection back to some Windows app. They even ensure that their entire client is friendly to URL rewriting if that's how your VPN works.

Ericom has a custom consulting service where they work with existing ISVs who want to "web enable" their applications, whether for their customers to do themselves or to convert the ISV into a SaaS provider.

And of course it's easy to see the value of adding AccessNow to an existing Quest vWorkspace or VMware View environment.

Pricing and licensing are pretty straightforward too. They have four licensing schemes: perpetual or subscription based, and per named user or per concurrent user. Prices for subscriptions cost just a few dollars per user per month, with perpetual licenses starting in the $60-range.

The bottom line

Ericom AccessNow HTML5 client: It's available today, they've made a lot of additions since it was first release and they've got a lot more on the way. And it works great with pure RDP, VMware View, Quest vWorkspace, and Ericom Powerterm Web Connect. And the price is right, especially if you buy the subscription. So if you need clientless access to your remote desktops, take a look at it. I'm a huge fan.

Dig Deeper on Citrix virtual desktops