trviewer

Where this sits next to AnyDesk and TeamViewer

Remote desktop is a solved category with entrenched products in it. AnyDesk and TeamViewer carry years of deployment, support organisations and compatibility work behind them, and we are not going to claim trviewer displaces them for a company already running one at scale.

What we can be specific about is what is inside ours. The encryption, the video pipeline and the network transport are code we wrote rather than a thin wrapper around somebody else’s sample. The rest of this page is about those three layers, because they are the only honest reason to look at a fourth remote desktop.

Keys the relay does not hold

A session is encrypted with AES-256-GCM and the key is agreed directly between the two endpoints by ECDH. The relay in the middle forwards bytes it cannot read: traffic is never decrypted there.

That is a constraint rather than a slogan, and it takes options away. A relay that cannot read the stream cannot transcode it for a weak client, cannot cache anything, and cannot inspect a session when you want to debug one. We took the trade because a support tool with reach into every desktop in an organisation is precisely the wrong place to put a machine that can see the pixels.

Capturing frames without paying for them

Screen capture runs through DXGI Desktop Duplication, which hands frames over from the GPU instead of reading the desktop back through the CPU. Encoding is H.264.

The part that matters more than either is what happens when nothing moves. A desktop under a support session is static most of the time, because somebody is reading, or talking, or thinking. No frames are produced while the screen is unchanged, so an idle session costs almost nothing in bandwidth or CPU and the budget is still there when the screen finally does change.

Two transports for one session

Transport is hybrid UDP and TCP with XOR forward error correction and an adaptive bitrate. UDP carries the video, because a late frame is worthless and asking for it again only makes the next one later; TCP carries what must not be lost.

Forward error correction means a certain amount of loss is repaired from data that has already been sent rather than by requesting a retransmission. That is the difference between a session that degrades on a bad line and one that stalls on it. Packet loss changes the picture; it does not drop the session.

This is the layer that decides, more than any other, whether a remote session over a mobile connection is usable or infuriating.

Three clients, one protocol

The desktop client is Windows and Qt6, the browser client runs over WebRTC with nothing to install, and there is a mobile client. They speak the same protocol rather than being three products that happen to share a name.

The browser client is the one that changes how support actually goes. The person being helped does not have to be talked through an installer and a permission dialog before anything can be fixed, which is the step where a lot of remote support calls quietly fail.

Unattended access, files and several screens

A session carries multi-monitor support, file transfer and a shared clipboard, and machines can be configured for unattended access so a server or a workstation is reachable with nobody sitting in front of it.

These are table stakes rather than differentiators. They are listed because their absence makes a remote desktop unusable in practice, not because they are the interesting part.

What we are not claiming

trviewer is our own product and we run it, but the honest position is that it is young against incumbents with a decade of edge cases behind them. If what you need is a remote desktop already deployed across ten thousand endpoints in your industry, that is not an argument we can win today.

The case for looking at it is narrower. You want to know exactly what the encryption does, where the keys live and what happens to the stream in the middle, and you want the people who wrote those layers to be reachable when you ask. That is a real requirement for some buyers and irrelevant to most, and we would rather say which one you are than pretend everybody needs it.