Skip to content

Network Requirements

How Remotle Connects

This page explains how a session is set up between a user’s device and a workstation. It is for IT teams who want to understand what they see in firewall logs and in the app’s Diagnostics, and for anyone deciding whether their network needs changing. It does not.


TCP 443, always

TCP 443, always

UDP 4443

UDP 4443

UDP, direct, when the network allows

Remotle clienton the user's device

Connection serviceComputle

RelayComputle

Remotle hoston the workstation

TCP 443, always

TCP 443, always

UDP 4443

UDP 4443

UDP, direct, when the network allows

Remotle clienton the user's device

Connection serviceComputle

RelayComputle

Remotle hoston the workstation

PartyRoleSees the session content
Remotle clientAsks for a workstation, checks the workstation’s identity, decodes the pictureYes, it is one end
Connection serviceChecks the user may connect to that workstation, introduces the two ends, hands each a secret for this sessionNo. It never carries the picture, sound or input.
RelayForwards encrypted packets between the two ends when no direct path exists. Computle operates relays in London, New York and Canada.No. The session is encrypted end to end between the client and the host, and the relay is never given the session keys.
Computle (Remotle) HostStreams the desktop, applies inputYes, it is the other end

Both the client and the host connect outbound to the connection service over TCP 443 and keep that connection open. The host sends a heartbeat every 30 seconds; a host that misses heartbeats for 90 seconds is shown as offline. Because every connection is made outbound, nothing on the workstation or the user’s device listens on a port.


RelayRemotle hostConnection serviceRemotle clientRelayRemotle hostConnection serviceRemotle clientThe host registered when it started and holds the connection openpar[Relay path][Direct path]TLS 1.3 handshake. The client checks the workstation certificate.Both ends prove they hold the session secret.The first path to complete carries the sessionConnect to this workstation (single-use token, 5 minutes)Check the token, the user and the workstationAllocate a session on one or more relaysSession id, relay list, the certificate to expect, session secretA client is coming: session id, relay list, session secretJoin the relayJoin the relayLearn own public address (STUN)Learn own public address (STUN)My addressMy addressThe host's addressThe client's addressProbe each other's addressFirst frame
RelayRemotle hostConnection serviceRemotle clientRelayRemotle hostConnection serviceRemotle clientThe host registered when it started and holds the connection openpar[Relay path][Direct path]TLS 1.3 handshake. The client checks the workstation certificate.Both ends prove they hold the session secret.The first path to complete carries the sessionConnect to this workstation (single-use token, 5 minutes)Check the token, the user and the workstationAllocate a session on one or more relaysSession id, relay list, the certificate to expect, session secretA client is coming: session id, relay list, session secretJoin the relayJoin the relayLearn own public address (STUN)Learn own public address (STUN)My addressMy addressThe host's addressThe client's addressProbe each other's addressFirst frame
  1. The request. The user picks a workstation. The client sends the connection service a token from the sign-in, which names the user and the workstation, lasts 5 minutes and can be used once.
  2. The introduction. The connection service checks the token, confirms the user may connect to that workstation, and allocates the session on a relay. It gives both ends the session id, the relay to use, and a secret for this session. The client is also told exactly which certificate the workstation must present.
  3. The race. Both ends start two paths at once. The relay path joins the relay from each end. The direct path has each end learn its own public address from a STUN server, exchange addresses through the connection service, and send probes to each other. The race lasts up to 3 seconds. The relay usually completes first, so the direct path is given a 700 millisecond head start before the relay is allowed to win.
  4. The checks. On whichever path completes, the two ends perform a TLS 1.3 handshake over QUIC. The client checks that the workstation’s certificate is the one the connection service named and was issued by Computle for that workstation and that organisation. Both ends then prove they hold the session secret. A relay that forwarded the packets cannot pass either check.
  5. The session. The first path to pass both checks carries the session. One QUIC connection carries video, audio, keyboard, mouse, pen, clipboard and USB. The host creates its virtual monitors and sends the first frame.

See Security for what each check protects against.


DirectRelay
RouteStraight between the user’s device and the workstation, over UDPThrough a Computle relay in London, New York or Canada, over UDP 4443
WhenWhen both networks let a UDP flow through after the probes, which most home and office routers doAlways available. Used when the direct path fails, or until it succeeds.
LatencyThe lowest the network allowsAdds the round trip to the relay
EncryptionTLS 1.3 over QUIC, end to endTLS 1.3 over QUIC, end to end. The relay sees encrypted packets only and applies a bandwidth cap and a duration limit to each session.
Shown in the app asDirectRelay, with the relay’s name

A session that starts on the relay keeps trying for a direct path: 10 seconds after it starts, then 20, 40 and 80 seconds, then every two minutes. When a direct path is found it is tested for 3 seconds before it carries anything, and the session moves to it without interruption. If the direct path then goes quiet for half a second, the session moves back to the relay. For its first 10 seconds the direct path must also carry at least a quarter of what the relay carried; if it does not, the session moves back to the relay and that workstation stays on the relay from that device for 30 minutes.

Users can see which path a session is on in Connection Figures. An administrator can see what the device can reach in Diagnostics.

Computle operates relays in London, New York and Canada. The connection service offers the client the relays it may use, nearest first, and the client races them. The first to complete carries the session, which is normally the nearest. One other relay is kept warm as a standby, so if the relay in use stops answering, the session moves to the standby without reconnecting.

The relays and their addresses are listed on Network Requirements.


EventWhat happens
The device moves network, for example Wi-Fi to a phone’s hotspotThe session continues from the new address. The host recognises the same session rather than a new client, so nothing is torn down.
The connection to the connection service dropsEach end reconnects to it on its own. The session between the two ends is unaffected.
The connection service instance is unavailableEach end moves to the next one in its list and comes back to its preferred one when that is healthy again.
The relay in use stops answeringThe session moves to the standby relay.
The session is interruptedThe client holds a resume ticket, valid for 12 hours, that lets it re-establish the session without signing in again. A resumed session gets fresh secrets.
The workstation restartsThe host registers again when it starts. The client reconnects.

ItemValue
Host heartbeatEvery 30 seconds, 90 seconds grace
Connection token5 minutes, single use
Path raceUp to 3 seconds
Direct path head start over the relay700 milliseconds
Direct path retries from a relayed session10, 20, 40, 80 seconds, then every 2 minutes
Direct path test before use3 seconds of answered probes
Relay keepaliveEvery 15 seconds. A relay session with no traffic for 60 seconds is closed.
Resume ticket12 hours
Workstation certificate30 days, renewed at day 20 with a new key. See Certificates and Identity.

Do I need to open a port for the direct path?

Section titled “Do I need to open a port for the direct path?”

No. The direct path uses the mapping your router creates when the device sends its first packet out, the same way video calls do. If your router does not allow that, the session uses the relay.

Can I force every session through the relay, or always direct?

Section titled “Can I force every session through the relay, or always direct?”

Yes, on Windows and Mac, per device. Settings, Preferences, Network Path offers Auto, Prefer direct, Relay only and Relay only (TCP). See Choosing the Network Path. On Auto, which is the default, the relay is always tried, so a session connects even where the direct path fails.

Does the connection service see my screen?

Section titled “Does the connection service see my screen?”

No. It carries the introduction and nothing else. Once the two ends have met, it is only used for the heartbeat and for setting up the next session.

No. The session is encrypted end to end with TLS 1.3 over QUIC between the user’s device and the workstation. The relay forwards packets it cannot decrypt, and it is never given the session keys. See Security.

What does a session use when the user’s network blocks UDP?

Section titled “What does a session use when the user’s network blocks UDP?”

Nothing. The session is carried over UDP on both paths, so a network that blocks all outbound UDP cannot start a session. The app’s Diagnostics shows this as Relays and STUN failing. See Network Requirements.