In a post-COVID world (knock on wood), remote working has solidified itself as a normal part of all of our lives. Even as we begin to trickle back to our physical offices, many experts expect that remote working is here to stay—if not in the exclusive manner it has recently been mandated, then in an occasional manner alongside local working, a scheme called hybrid working. A worker can be in the office one day and at home the next, and as long as the work gets done, everybody’s better for it.

But in order to accommodate this anticipated hybrid workflow, remote working solutions remain in high demand. These solutions can be pretty straightforward, like replacing a desktop computer with a laptop. Data reveals that many have done just that. Globally, laptop and mobile workstations sales increased 25 percent from 2019 to 2020. Lenovo’s General Manager of Workstations, Rob Herman, reported a reversal in desktop and mobile workstation sales before and during the pandemic: from 40 percent mobile and 60 percent desktop before the pandemic to 60 percent mobile in the midst of COVID-19.

As powerful as modern mobile workstations have become, they are always constrained by their size, never quite reaching the heights of their stationary counterparts. For users who require the most powerful hardware—users like engineers—a desktop workstation remains the better choice. But now we’re back where we started. We’ve traded the hybrid flexibility of a mobile workstation for the local power of a desktop tower. Is there a way to keep both?

Remote Desktops, VDI, and DaaS

There is a way to keep both flexibility and power, and it’s called a remote desktop. In essence, a remote desktop is a computer that’s located in one spot and accessed from another. For example, a desktop workstation in an office that’s controlled from a lightweight laptop in a user’s home is a remote desktop. A remote desktop could also be a virtual machine running on a server, or even just a single virtual application. If the compute is happening over there and the output is showing up over here, it’s a remote desktop.

COVID didn’t create the concept of a remote desktop, which has existed since the late 1980s, but it did put a fine point on the benefits of remote desktops. They disentangle a user’s local hardware (which could be as cheap as a Chromebook) from their effective hardware (which could be a graphical powerhouse). Not only does this give the user unlimited access to that powerful hardware, it makes IT administration simpler, increases data security, and lowers hardware costs. For instance, two users could share the same workstation, each using it at different times, or each virtualizing their own desktop for simultaneous access on the same hardware.

There are a few common approaches to remote desktops. In the simplest case, a user can remote into their personal desktop workstation, the one that sits next to their desk at the office. The remote desktop becomes a real desktop when they go into work.

A more sophisticated approach is called virtual desktop infrastructure, or VDI. A VDI solution is designed by an IT department to serve some or all of the employees of a given organization, typically virtualizing desktops or applications with a specific software solution and sending that to the end-user devices. The remote desktop could also be a physical machine, such as the BOXX FLEXX server system we reviewed earlier this year.

A third, more recent approach to remote desktops is called desktop-as-a-service, or DaaS. This works the same way as VDI, only it’s managed by a third-party and the hardware exists in a public cloud like Amazon Web Services (AWS). There are many DaaS providers, such as BOXX Cloud (which manages FLEXX servers on your behalf) and Amazon WorkSpaces, which rents out virtual desktops on the AWS cloud.

What is a Remote Desktop Protocol?

There are a lot of choices that go into a remote desktop solution, but one of the most important is the choice of remote desktop protocol. A remote desktop protocol describes the way that the remote desktop (which we’ll start calling the server) interacts with the end-user device (which we’ll start calling the client). Remote desktop protocols are also known as remote display protocols.

There are dozens if not hundreds of remote desktop protocols, such as Teradici PCoIP, Citrix ICA, HP ZCentral Remote Boost, Mechdyne TGX, Microsoft RDP, and many others. Each of these protocols operates a little bit differently, tuning their many available dials one way or another based on what they’re trying to achieve. Some protocols prioritize network bandwidth, doing everything they can to ensure that they can function over poor networks. Other protocols try to optimize end-user experience, trading off higher bandwidth requirements for a better quality at the client.

For engineering workflows, it is particularly important to ensure a high quality user experience. A 10-minute remote technical support session can get away with some grain or lag. An 8-hour CAD marathon, on the other hand, would be unthinkable with such sacrifices. That’s the first thing to understand about remote desktop protocols: the best protocol depends on the user in question.

“Everybody’s perspective of what’s tolerable and not is their own,” stated Cathy Lascara, Software VP and TGX Lead at Mechdyne. “We’ve had some users say ‘I can’t use it. It’s too slow. I can just tell it’s not perfect.’ Then you’ve got others who say ‘There was a little bit of lag, but it didn’t slow down my ability to interpret what I was doing.’”

That’s the second thing to understand about remote desktop protocols: they’re not perfect. They can’t be perfect. They can only asymptotically approach a local experience. The trick is to get them close enough to that experience that even the pickiest of users—engineers, perhaps—will not complain.

“With COVID people had to deal with [remote desktops], and I think they found out that it wasn’t nearly as bad as they thought it was going to be,” Lascara said.

In fact, remote desktop protocols are getting better by the day. But of the many available, which is the best remote desktop protocol for engineers? In engineering.com’s most recent research report, What’s the Best Remote Desktop Protocol for Engineers?, we set out to answer that very question. We’ll present some of our findings below, but for complete details, download the full report.

Encoding for Engineers

One of the biggest dials that’s adjusted by a developer of remote desktop protocols is the encoder. In a remote desktop, data about the server’s display is encoded, sent across the network to the client, and then decoded. For many protocols, the data is just pixels—it’s like watching a live video of the server. Some protocols, in contrast, send graphical function calls from the server, rather than pixels, but this approach is far less popular today than it once was.

Video data takes up a lot of space, so to send it over the network, it must first be encoded—that is, compressed in a specific way called a coding format. The most popular video coding format today is called H.264, though there are many others. H.264 provides a balance between network performance and lossiness that has made it popular for video streaming sites and remote desktop protocols alike.

When you’re watching a video encoded with H.264, you probably won’t much notice what’s been lost in transmission. There’s too much movement on screen to hone in on the imperfections. But if the movement stops—like when you’re trying to read static text on a webpage—the losses come into sharp focus. Or rather, just the opposite.

“The problem with H.264 is that it can’t deal with anti-aliased text and it can’t deal with wireframes… [they] get smudged, and that’s very tiring on the eyes,” explained Ian Main, Technical Marketing Principal at Teradici, developer of the PCoIP remote desktop protocol.

To solve this problem, PCoIP and many other remote desktop protocols support multiple coding formats in addition to H.264. In this way, users can pick the optimal coding format for their needs. Some remote desktop protocols can even switch coding formats on the fly, as the user switches from watching a video to reading an email. PCoIP does this with a feature called PCoIP Auto Offload. But there’s one step even further: supporting multiple coding formats in one frame. Citrix ICA’s selective encoding feature does this by identifying distinct regions of a display and coding them separately for the best result.

“Taking an entire screen and encoding it with a video codec like H.264 may be great for performance and frame rates, but it’s pretty bad for text or sharp images. So [we] get the best of both worlds when it comes to encoding a screen,” claimed Roberto Moreno, Principal Product Manager at Citrix.

A Local Experience for Remote 3D Mice, Wacom Tablets, and Other Peripherals

Engineers can be particular about the way they work, and there are few who would be willing to radically change their setup for the sake of a remote desktop. Consider a CAD user who relies on a 3D mouse like the 3Dconnexion SpaceMouse. These are niche devices, even among CAD pros, some of whom simply can’t switch from the plain 2D mouse they’ve mastered over the years. But users of 3D mice love their 3D mice; it’s non-negotiable. The same mentality holds for the few of us who use a Wacom tablet or other graphics pad, or perhaps some other peripheral more niche still.

Almost every remote desktop protocol is capable of sending USB data from client to server, which means that you can plug in almost any USB device (including flash drives) and expect it to work. But the problem is it probably won’t work very well.

“It takes some custom work to get a good experience per USB device versus just remot[ing] USB,” explained Christian Jones, Strategy and Business Planner for Z by HP, developer of the ZCentral Remote Boost protocol. HP and other remote desktop protocol developers work closely with the manufacturers of these devices—Wacom, 3Dconnexion, etc.—to ensure that they work remotely the same way they would work at a local machine. Without this specialty work, a specialty peripheral may not function properly. A Wacom tablet may not recognize pressure or tilt, for instance.

On top of that, USB is “very chatty,” according to Jones, so merely passing along USB data can congest the network. This is a prime reason why several remote desktop protocols do not (yet) support webcams, even in this age of Zoom meetings. Passing the webcam data from client to server is costly and inefficient unless you put in some custom work. A few protocols, including PCoIP, Remote Boost, ICA, and VMware Blast Extreme have already implemented webcam support, and most of those that haven’t plan to do so at some point.

How To Choose a Remote Desktop Protocol for Engineering

While there are many remote desktop protocols available, only a subset of these are optimized for the kinds of highly-visual work done by engineers, designers, architects, and other visualization professionals. Some of the most prominent are those backed by major hardware manufacturers: HP naturally backs its own remote desktop protocol, ZCentral Remote Boost; Dell is a longtime partner of Teradici and backs the PCoIP protocol, as does BOXX; and Lenovo backs Mechdyne TGX (HP recently announced that it will acquire Teradici, so this balance may soon change).

Even among these engineering-focused protocols, there are differences in features and design that impact the end user. We have discussed a few such differences in this article, but there are many we have not: data security, network transport, screen sharing collaboration, display configuration, and server and client hardware are among the many factors to understand when evaluating a remote desktop protocol.