DW Cloud Overview

What is Cloud Connect?

-----------------------------------

Affected Roles: Owner, Administrator

Related Digital Watchdog VMS Apps: DW Spectrum IPVMS

Last Edit: January 16, 2023

-----------------------------------

Defining DW Cloud

DW Cloud is a feature of DW Spectrum that allows users to connect with DW Spectrum Servers through an Internet connection, without having to set up port forwarding.

Users can change between DW Spectrum Systems by connecting their Servers to their DW Cloud account, allowing easy access through the DW Spectrum desktop client, mobile application, or web client.

This article will outline how DW Cloud works and its requirements to operate.

**NOTE: For more information for setting up DW Cloud, please read DW Cloud Setup.

Supported/Affected Devices

DW Blackjack Series

DW Cloud Requirements

To use DW Cloud, at least one DW Spectrum Server with Internet access is required.

DW Cloud uses UDP Hole Punching to maintain Cloud Connect, omitting requirements to forward TCP ports. However, if your DW Spectrum Server is behind a Firewall or Sonicwall, DW Cloud will not be able to communicate until the DW Cloud services have been allowlisted.

Please use DW Spectrum - FQDN or Allowlist for DW Cloud Access for DW Cloud allowlisting information.

**NOTE: DW Cloud will not be able to establish a Client-to-Server connection in cases where users are utilizing a Symmetric NAT mode within their router(s).

Cloud Connect Services

Mediator

This intermediate service allows the DW Spectrum Server and connecting clients (each behind their own NAT) to discover each other’s network addressing information to establish a P2P (Peer-to-Peer) connection.

Relay (proxy)

This DW Cloud service is responsible for relaying traffic between the client and the media server, if UDP hole punching does not work.

DW Spectrum Server

When the DW Spectrum Server application starts, it reports the local IP addresses to the Mediator. The Server then connects to the Relay and waits for incoming requests.

This is necessary in cases where the Media Server is installed on a machine that is assigned to a public IP address.

DW Spectrum Client

If the DW Spectrum Server can be found in a LAN (Local Area Network) using multicast, the client establishes a direct TCP connection to that server. In this case, the Mediator is not used.

Otherwise, the DW Spectrum Client sends a connection request to the Mediator. The Mediator responds with all known addresses of the Media Server, including TCP addresses (forwarded and local) and the UDP address that was obtained when punching a hold in the NAT.

After receiving this information, the client tries to establish a connection to every address simultaneously. Meanwhile, the DW Spectrum Client tries to connect with the Media Server through the DW Cloud Relay service.

**NOTE: By default, there is no preference set between TCP or UDP to minimize connection time. Setting a preference to either protocol increases connection time.

NAT Traversal Methods

UDP Hole Punching (Punch-Through)

NAT allows a host to send UDP packets to some public UDP services.

Here is an example exchange:

When the host sends a UDP packet, NAT allocates a public port (port1 on address ip1) for that packet, sending the request as if it had been sent from IP1:port1.

When this service sends a response back to ip1:port1, NAT knows that it is the Server awaiting a response to be forwarded.

When sending a UDP request from within NAT to the public network, NAT punches a virtual ‘hole’. This method is used to establish a reliable connection over UDP between two systems, each behind its own NAT.

**NOTE: UDP hole punching does not guarantee success in all cases. UDP hole punching success is dependent upon the DW Spectrum Client computer and DW Spectrum Server computer NAT types.

All NAT types, except for symmetric NAT, allows UDP hole punching. Yet, the presence of a firewall or SonicWall will block UDP traffic.

Algorithm

The Server connects to the Mediator after starting.

The Mediator identifies itself by providing its GUID and awaits connection requests. The Server maintains a TCP connection with the Mediator.

The Client sends a connection request to the Mediator through UDP, providing the GUID of a system or specific Server for connection.

The Mediator identifies the Server by its GUID, then sends a connection_requested message to the Server using the pre-established TCP connection (this message contains the Client’s UDP address).

**NOTE: The Client can specify the GUID of the System, not just a specific Server. In this case, the Mediator will select any online Server belonging to that System.

The Server opens a ‘hole’ to:
- Send a connection_ack request to the Mediator using UDP
- Initiates a UDP rendezvous connection with the Client address provided in the connection_requested message (i.e., sends a number of UDP packets to the Client).

The Mediator receives a connection_ack request from the Server and sends a connect_response message to the Client.

The Client receives a connect_response message and initiates a UDT rendezvous connection to the server address found in the connect_response. As a result, we now have a UDT connection between the DW Spectrum Server and the DW Spectrum Client.

Opening subsequent connections between the Server and the Client does not require these steps to be repeated. Having at least one active UDT connection means that ‘holes’ are punched in both NATs. Subsequent connections can be established with a regular UDT mechanism (similar to a TCP connection to a directly accessible address).

Relaying (proxying)

All traffic between the DW Spectrum Client and the DW Spectrum Server is relayed through the corresponding DW Cloud service. It is the Server and the Client that are responsible for encrypting traffic. The Cloud relay does not force encryption and does not distinguish SSL/non-SSL traffic when relaying.

The Server establishes a connection to the Relay and waits for a request from the Client.

The Client sends a request to the Relay, asking to provide a relayed connection to the Server.

The Relay uses an existing connection that was established by the Server to transfer the Client’s traffic back to the Server. Meanwhile, the Server establishes another connection to the Relay and waits for more requests from the Client.

To minimize client-side latency, the Server always keeps at least seven (7) inactive connections to the Relay. It is common for a Client to request multiple connections to the Server simultaneously.

Common Issues

The following problems may prevent connection to the Server:

The Server is behind a Squid-like HTTP proxy

This impacts the Server to Mediator UDP hole punching algorithm and the Server to Relay relaying connections.

The Squid (http://www.squid-cache.org/) does not support any kind of HTTP tunneling (e.g., WebSocket or POST with the infinite body).

As a result, the media server can have problems establishing a persistent HTTP connection to the Mediator or the Cloud Relay.

Other HTTP proxies and firewalls can have different limitations on HTTP dialect.

We address these limitations by introducing multiple HTTP tunneling methods, probing, and selecting the most suitable one for the location (introduced in the DW Spectrum v3.2 update).

UDP packets from the Cloud do not reach the Client

This impacts the Client to Mediator message exchange.

Various intermediate networking hardware or software (e.g., Firewall or SonicWall) may lead to non-working UDP. As a result, the response from the Mediator never reaches the Client, causing the connection to fail.

This is addressed by duplicating a UDP request with a TCP request (introduced in the DW Spectrum v4.0 update).