Skip to main content

Overview

Network configuration controls signaling server connections, matchmaker registration, ICE/TURN server setup for NAT traversal, and keepalive settings.

Client Configuration

Browser client connection endpoints.
client.serverUrlBase
string
required
WebSocket URL for the signaling server.Default: wss://signaling-server-production-acd4.up.railway.appMust use wss:// for secure WebSocket in production.Examples:
  • Development: ws://localhost:3002
  • Production: wss://signaling.example.com
Always use wss:// (secure WebSocket) in production to avoid security warnings and blocked connections.
client.matchmakerUrl
string
required
HTTP(S) URL for the matchmaker service.Default: https://matchmaker-production-5b36.up.railway.appMatchmaker assigns clients to available hosts.Examples:
  • Development: http://localhost:3000
  • Production: https://matchmaker.example.com

Host Signaling

host.signalingUrl
string
required
WebSocket URL for host-to-signaling-server connection.Default: wss://signaling-server-production-acd4.up.railway.appShould match client.serverUrlBase to ensure hosts and clients connect to the same signaling server.

Matchmaker Configuration

The matchmaker service manages host registration and client-to-host assignment.
host.matchmaker.url
string
required
HTTP(S) URL for matchmaker endpoint.Default: https://matchmaker-production-5b36.up.railway.appHost registers itself with this service and maintains keepalive.
host.matchmaker.hostSecret
string
required
Shared secret for host authentication.Default: HELLO-MFSUsed to authenticate host registration requests.
Change this to a secure random value in production! The default is for development only.
Generate a secure secret:
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
host.matchmaker.heartbeatIntervalMs
integer
default:"20000"
Host keepalive interval in milliseconds.Default: 20000 (20 seconds)Host sends periodic heartbeats to matchmaker to indicate availability.Recommended:
  • 10000-20000 - Standard (default)
  • 5000-10000 - Fast failover (higher network traffic)
  • 30000-60000 - Low traffic (slower failover)
Set to 2-3x your expected network latency for stable connections.

ICE and TURN Configuration

ICE (Interactive Connectivity Establishment) and TURN (Traversal Using Relays around NAT) enable WebRTC connections through firewalls and NAT.

Default Behavior

The CloudGaming host uses default ICE servers configured in the Pion WebRTC library. For most local networks and direct connections, this is sufficient.

Custom ICE/TURN Servers

For production deployments or restrictive networks, configure custom TURN servers in your WebRTC connection code. Client-side ICE configuration (JavaScript):
const iceServers = [
  { urls: 'stun:stun.l.google.com:19302' },
  {
    urls: 'turn:turn.example.com:3478',
    username: 'user',
    credential: 'pass'
  }
];

const pc = new RTCPeerConnection({
  iceServers: iceServers
});
Host-side configuration requires modifying the Go code in gortc_main/ to add custom ICE servers to the Pion WebRTC configuration.

Public STUN Servers

Free STUN servers for NAT traversal (no relay):
  • stun:stun.l.google.com:19302 (Google)
  • stun:stun1.l.google.com:19302
  • stun:stun.cloudflare.com:3478 (Cloudflare)

TURN Server Setup

For reliable connections through restrictive NATs, deploy your own TURN server: Using Coturn:
# Install
sudo apt-get install coturn

# Configure /etc/turnserver.conf
listening-port=3478
fingerprint
lt-cred-mech
user=myuser:mypassword
realm=turn.example.com

# Start
sudo systemctl start coturn
Deploy TURN servers geographically close to your users for best performance.

Redis Configuration (Signaling Server)

The signaling server uses Redis for pub/sub and multi-node scaling. Configure Redis connection in the signaling server deployment. Environment variables for signaling server:
REDIS_HOST=localhost
REDIS_PORT=6379
REDIS_PASSWORD=your_secure_password
Always use Redis authentication (requirepass) in production deployments.

Network Architecture

Connection Flow

  1. Client → Matchmaker: Request available host
  2. Matchmaker → Client: Return host ID
  3. Client → Signaling: Connect via WebSocket
  4. ClientHost: Exchange SDP/ICE through signaling
  5. ClientHost: Establish direct WebRTC P2P connection
  6. ClientHost: Stream video/audio, receive input

Components

┌─────────┐          ┌────────────┐          ┌──────┐
│ Client  │ ◄─────── │ Signaling  │ ◄─────── │ Host │
│(Browser)│   WSS    │   Server   │   WSS    │ (C++) │
└─────────┘          └────────────┘          └──────┘
     │                     │                     │
     │                     ▼                     │
     │               ┌──────────┐                │
     └─────────────► │  Redis   │ ◄──────────────┘
          HTTP       │ Pub/Sub  │       HTTP
                     └──────────┘
     │                                           │
     │               ┌────────────┐              │
     └─────────────► │ Matchmaker │ ◄────────────┘
          HTTP       │  Service   │      HTTP
                     └────────────┘
     │                                           │
     └───────────────────────────────────────────┘
                    WebRTC P2P
              (video, audio, input)

Firewall and Port Configuration

Required Ports

ServiceProtocolPortDirection
Signaling ServerWSS3002 (or custom)Inbound
MatchmakerHTTPS3000 (or custom)Inbound
STUNUDP3478Bidirectional
TURNUDP/TCP3478Bidirectional
WebRTC MediaUDP10000-65535Bidirectional

Firewall Rules (Host)

Allow outbound connections:
  • WSS to signaling server
  • HTTPS to matchmaker
  • UDP for WebRTC media
# Example iptables (Linux host)
iptables -A OUTPUT -p tcp --dport 3002 -j ACCEPT  # Signaling
iptables -A OUTPUT -p tcp --dport 3000 -j ACCEPT  # Matchmaker
iptables -A OUTPUT -p udp --dport 3478 -j ACCEPT  # STUN/TURN
iptables -A OUTPUT -p udp -m udp --dport 10000:65535 -j ACCEPT  # WebRTC
WebRTC requires bidirectional UDP traffic. Highly restrictive firewalls may block P2P connections, requiring TURN relay.

Production Deployment Checklist

Use secure protocols (wss://, https://) for all endpoints
Change hostSecret to a cryptographically secure random value
Deploy Redis with authentication enabled
Configure TURN servers for NAT traversal
Set up SSL/TLS certificates for signaling and matchmaker
Configure firewall rules to allow required ports
Set appropriate heartbeatIntervalMs for your network
Test connections from restrictive networks (corporate, mobile)

Example Configurations

Local Development

{
  "client": {
    "serverUrlBase": "ws://localhost:3002",
    "matchmakerUrl": "http://localhost:3000"
  },
  "host": {
    "signalingUrl": "ws://localhost:3002",
    "matchmaker": {
      "url": "http://localhost:3000",
      "hostSecret": "dev-secret-123",
      "heartbeatIntervalMs": 25000
    }
  }
}

Production Deployment

{
  "client": {
    "serverUrlBase": "wss://signaling.cloudgaming.example.com",
    "matchmakerUrl": "https://matchmaker.cloudgaming.example.com"
  },
  "host": {
    "signalingUrl": "wss://signaling.cloudgaming.example.com",
    "matchmaker": {
      "url": "https://matchmaker.cloudgaming.example.com",
      "hostSecret": "YOUR_SECURE_SECRET_HERE",
      "heartbeatIntervalMs": 20000
    }
  }
}

High-Availability Setup

{
  "client": {
    "serverUrlBase": "wss://signaling-lb.example.com",
    "matchmakerUrl": "https://matchmaker-lb.example.com"
  },
  "host": {
    "signalingUrl": "wss://signaling-lb.example.com",
    "matchmaker": {
      "url": "https://matchmaker-lb.example.com",
      "hostSecret": "YOUR_SECURE_SECRET_HERE",
      "heartbeatIntervalMs": 15000
    }
  }
}
Additional infrastructure:
  • Multiple signaling server instances behind load balancer
  • Redis cluster for high availability
  • Multiple matchmaker instances
  • Geographically distributed TURN servers
For high-availability deployments, use health checks on the load balancer and reduce heartbeatIntervalMs to 10-15 seconds for faster failover.

Troubleshooting

Cannot Connect to Signaling Server

Check:
  1. Signaling server is running and accessible
  2. WebSocket URL uses correct protocol (ws:// vs wss://)
  3. Firewall allows outbound connections on signaling port
  4. SSL certificate is valid (for wss://)

Host Not Appearing in Matchmaker

Check:
  1. Matchmaker service is running
  2. hostSecret matches on host and matchmaker
  3. Host can reach matchmaker URL
  4. Heartbeats are being sent (check logs)
  5. Matchmaker Redis connection is working

WebRTC Connection Fails (ICE Failed)

Check:
  1. STUN/TURN servers are reachable
  2. UDP traffic is not blocked by firewall
  3. NAT type is compatible (symmetric NAT requires TURN)
  4. ICE candidate gathering completes successfully
  5. Consider deploying TURN server for relay

High Latency

Check:
  1. Network RTT between client and host
  2. TURN relay is not being used (adds latency)
  3. Signaling server geographic location
  4. Client/host network quality

Intermittent Disconnections

Check:
  1. heartbeatIntervalMs is appropriate for network latency
  2. Redis pub/sub is stable
  3. Load balancer timeout settings
  4. Network stability (packet loss, jitter)