Network Dock / LAN Dock — make the workstation location-independent

Creators & Developers
1

A normal USB-C/Thunderbolt dock connects peripherals to a computer sitting nearby. I’m proposing a dock where the upstream connection is the network instead: displays, USB, audio and input devices terminate at the dock, while the selected computer can be elsewhere over Ethernet or Wi-Fi.

The basic idea is to make the physical location of the computer largely irrelevant. A workstation could sit in another room, a server rack, elsewhere in the building, or—where network latency permits—even at another site. The desk would contain only the monitor/dock and peripherals. The dock could also switch between several available computers, much like a KVM switches between directly connected machines today.

This would not primarily be a conventional remote-desktop device. Input, display, audio and peripheral traffic would be treated as first-class parts of the connection, optimized independently for low latency. HID traffic could be forwarded immediately, while display and audio use dedicated low-latency streams. Ethernet would provide the best latency and reliability, while Wi-Fi could provide a convenient wireless mode.

A basic version could remain deliberately simple and inexpensive: 2.5GbE, optional Wi-Fi, hardware video decoding, USB, audio and one or two display outputs. A premium version could add 10GbE, higher refresh rates, better jitter mitigation and more displays.

The same design could also be integrated directly into a USB-C hub monitor. Modern hub monitors already contain USB hubs, Ethernet, KVM functionality, audio and display switching; the main conceptual change would be allowing the upstream computer to be reached over the network rather than requiring it to sit at the other end of a USB-C/Thunderbolt cable.

The protocol/client side would not necessarily have to be limited to dedicated dock hardware either. An ordinary PC could potentially run a software client and act as an endpoint for the same workstation. The physical dock would then be the purpose-built version for a desk where you don’t want or need another complete PC just to access the remote one.

For a higher-end dock, the SoC needed for decoding, buffering and managing the connection might incidentally be powerful enough to provide a very lightweight local desktop when no remote computer is available. I would treat that strictly as a bonus, though—the device should remain a dock first, not turn into a mini-PC.

The intended use spans both ordinary office/workstation tasks and latency-sensitive uses such as gaming: locally it should aim to feel like a directly connected dock, while longer-distance connections would trade some responsiveness for reach.

2

You’ve just reinvented dumb terminals, which is what Wyse was. They were surprisingly expensive, because like you’ve kinda alluded to, you pretty much end up having a full computer anyways.
You can do this yourself using something like a Raspberry Pi and set it up so that it is connecting to a X11 session somewhere else. I don’t think Wayland works like that anymore.

Edit to add: The other search term is “thin client” instead of dumb terminal … I couldn’t remember that name.

1 Like
3

Looks and smells like thin clients that already exist, but non-Server Windows licences are single-seat. They don’t allow multiple users to share hardware, which is weird in an era where videoconferencing and streaming video come to us over the internet and almost all the GenAI work goes up to remote hosts and back again to us. That’s to say that there’s a problem with the kind of software that most people run still living in Bill Gates’s 1975 desire for “a computer on every desk and in every home.”

I’d take a “supported” set of Framework software to run on an old FW13 mainboard and tunnel peripherals over TB3 or USB4 (40gbps) to another device, ideally by Framework, in another room. I want to reuse older hardware I have already bought, say after an upgrade that leaves have spare parts left over, and this wouldn’t incur any hardware development costs for Framework Org. I doubt it woould use all the resources in our older device, so I’d suggest adding an OCI container runtime which lets containerized workloads from the remote host take up CPU/RAM resources on the older hardware.

4

Any reason you don’t just buy a low ram variant of an RPI 4/5 to be the “dock” and run a lightweight distro with sunshine / moonlight?

It seems like it would tick all your boxes - sunshine is meant for low latency applications, has encryption support for inputs and optionally display, handles compression/decompression of the video stream for lower bandwidth network links.

It’s honestly kinda hard to imagine a dedicated dock ends up being much cheaper than that.