Server + client system / Multi-surface

RemotePad

A remote control system made of a Windows server, a mobile client and a shared message model that defines the protocol between them.

Role: Protocol design, server, mobile client and integration Duration: Own project 2026

The problem

Controlling a machine from a phone looks like an interface problem, but it is not: it is a protocol problem. Before the touch surface can feel natural, you have to decide which messages exist, who originates them, what happens when they are lost, and how two devices that never met pair up.

Two surfaces, one contract

Constraints

The server needs elevated permissions to act on the operating system
Perceived latency of the touch gesture is the quality bar
Local-network pairing with no manual configuration

Decisions

Chose A contracts project shared between server and client

Instead of Defining messages at each end and keeping them in sync by hand

Because The protocol is the real product. Sharing its definition turns a desync into a compile error.

Chose A persistent bidirectional channel instead of discrete requests

Instead of An HTTP call per gesture

Because The cost of establishing a connection per event is incompatible with a pointer that has to follow a finger.

Chose Concentrate operating-system integrations in the server

Instead of Splitting capabilities across both ends

Because The client must be able to change platform without dragging along the other side's OS dependencies.

Outcome

Shared message model defining the protocol
Mobile client with touch controls on an MVVM pattern
Windows server with keyboard, pointer and screen capture integrations
Local-network pairing flow

It is a system, not an app

The visible part is an app on a phone. The part that matters is spread across three pieces: the server acting on Windows, the client capturing the gesture, and the message model defining what each can say to the other.

That third project — the contracts — is what lets the other two evolve separately. A new message is added in one place and both ends stop compiling until they handle it. That is exactly the behaviour you want from a protocol.

Why it belongs here

Because the same pattern — two distinct surfaces communicating through an explicit contract — is what holds up the large systems I work on. Here it is in its smallest complete form, which is why it reads at a glance.