Kanda Foundation 0.8.0
Loading...
Searching...
No Matches
Room Servers

This page explains how Room Servers work to facilitate communication between clients and dedicated servers.

Overview

Room Servers provide a system for tracking, managing, and sharing data between clients and dedicated servers in server-hosted sessions. They integrate with both Unity's Multiplay service for server allocation and Unity Relay for WebSocket connections.

Distributing Server Builds

To build and distribute dedicated server code, we provide an editor tool which can be found at (Kanda SDK > Distribution > To Unity Multiplay Hosting...).

This tool helps automate the build process, and upon entering Unity Cloud Service Account credentials with the Game Server Hosting API Manager for your project, you can upload your build to a new or existing Multiplay Build Configuration.

Server Allocation Flow

When a client requests a server-hosted session, the following process occurs:

  1. The client calls the Kanda Cloud Room Server Join endpoint with session/room information
  2. Kanda Cloud initiates server allocation
  3. The Join endpoint returns the current status of the server:
    • Queued - Server allocation has been requested
    • Starting - Server is booting up
    • Running - Server is ready for connections
    • Error - Server failed to start
  4. The client polls the Join endpoint until server status is Running
  5. Once running, the Join endpoint provides connection details:
    • For UDP connections: Server IP and port
    • For WebSocket connections: Unity Relay join code

Server Authentication

Room Servers need to communicate with Kanda Cloud to share information with clients. This is handled through a secure authentication process:

  1. When Kanda Cloud allocates a server via Unity Multiplay, it includes temporary credentials in the allocation payload
  2. The server retrieves these credentials from the allocation payload on startup
  3. These credentials allow the server to interact with designated Kanda Cloud endpoints
  4. The credentials are scoped specifically to that server instance and expire after the server shuts down

WebSocket Connections

When WebSocket connections are enabled in the SDK settings, additional steps occur during server startup:

  1. Server boots and retrieves credentials from allocation payload
  2. Server creates and connects to a Unity Relay allocation to enable WebSocket connections
  3. Server obtains a join code for the Relay allocation
  4. Server shares this join code with clients via Kanda Cloud Room Server Update endpoint
  5. Clients receive the join code through the Room Server Join endpoint
  6. Clients connect to the server through Unity Relay using WebSockets

Server Allocation Timing

Room Server allocation is an asynchronous process that can take time:

  1. Initial allocation request may queue the server
  2. Server must be started on Unity Multiplay infrastructure
  3. Server must complete boot process and initialize services
  4. For WebSocket connections, Relay setup adds additional steps

UI can handle this by polling the Join endpoint and tracking server status. This allows clients to:

  • Queue a server allocation
  • Monitor allocation progress
  • Connect once server is ready
  • Timeout if allocation takes too long

Example Status Flow

Client → Join Request → "Queued"
Client → Poll Join → "Starting"
Client → Poll Join → "Starting"
Client → Poll Join → "Running" → Connect