Source

How connections work

When you connect by ID, Remora works like TeamViewer: a server introduces the two computers, then gets out of the way. The screen data takes the cheapest route that works.

The three routes

1

LAN direct (TCP)

If both computers appear behind the same public IP, the host has shared its LAN address with the server, and the viewer connects to it directly.

2

Peer-to-peer (UDP hole punching + QUIC)

Otherwise both sides punch through their routers and connect directly over QUIC. This works through most home and mobile routers.

3

Relay (TCP)

If a network blocks that (some offices, some carriers), both connect to the server, which forwards the encrypted bytes between them.

The toolbar shows which one you got: direct, peer-to-peer or relayed. In a local test, the time from clicking connect to working remote control was about 0.75 s over peer-to-peer.

Step by step

Always online

When the app starts, the host opens a connection out to the server and registers its ID. Routers always allow outgoing connections, which is why nobody has to touch router settings. A small heartbeat every 15 s keeps it alive.

Asking for an ID

The viewer asks the server for the ID. The server creates a random one-time token and tells the host that someone with this token is coming.

Hole punching

Both sides then do the following, using the token:

  1. Each opens a UDP socket and sends a hello with the token to the server from that socket. The router creates a mapping for it, so the server sees each side's public address and port.
  2. The server tells each side the other's public address.
  3. Both fire small packets at each other. To each router, the partner's traffic now looks like a reply to something its own computer sent, so it lets it in.
  4. QUIC starts on that same socket: the host acts as the server, the viewer as the client. One stream carries the whole session.
text
 viewer                      server                       host
   │ ── hello(token) ─────────▶ │ ◀───────── hello(token) ── │
   │ ◀── your partner is at… ── │ ── your partner is at… ──▶ │
   │ ════════════ punch packets, then QUIC, directly ═══════ │

Falling back

If no answer arrives within a few seconds, the viewer joins the relay: both open a TCP connection to the server with the token, and the server splices the two connections together.

What the server does during a session

PhaseThrough the server?
Registration and heartbeatsYes, tiny messages
Looking up an ID, exchanging addressesYes, briefly (a few hundred bytes)
The session itself (direct or peer-to-peer)No, straight between the computers
The session itself (relayed)Yes, but still end-to-end encrypted

Firewall-friendly fallback

If the configured server port is blocked, the app retries on port 443. It remembers which port worked and uses it for the relay and the UDP exchange too, so peer-to-peer can still work on networks that only allow web ports, provided the server listens on 443.

Settings that affect routing

  • Settings → Peer-to-peer connections: off means always use the relay.
  • Settings → Direct connections: off means this computer doesn't accept LAN or IP connections.
Command lineSecurity