Network Architecture

Network Architecture

Portal exposes two listeners:

• Player listener (network.address, default :19132) — where players connect. Its transport is NetherNet (Bedrock's WebRTC-based transport) by default, or RakNet if network.transport is set to "raknet". Either way it's a single address; see NetherNet Transport for what actually changes underneath.
• Socket API listener (network.communication.address, default :19131) — a TCP socket backend servers connect to, to register themselves and talk to the proxy. See Socket Protocol.

Backend servers are independent of the player listener's transport: each one declares its own transport (RakNet or NetherNet) when it registers, and Portal dials each accordingly. A single Portal instance can front a mix of RakNet-only, NetherNet-only, and dual-transport backends at the same time — see Backend Transports.

                         ┌──────────────────────┐
                         │     Portal Proxy      │
                         │                       │
  Bedrock Players ──────▶│  :19132 (players)     │
                         │  :19131 (socket API)  │
                         │                       │
                         └───┬──────┬──────┬─────┘
                             │      │      │
                    ┌────────┘      │      └────────┐
                    ▼               ▼               ▼
             ┌────────────┐  ┌────────────┐  ┌────────────┐
             │ PocketMine │  │ Dragonfly  │  │  GeyserMC  │
             │ (PortalPM) │  │ (PortalDF) │  │ (Portal-   │
             │            │  │            │  │  GeyserMC) │
             └────────────┘  └────────────┘  └────────────┘

How a connection flows

1. A player connects to Portal's player listener.
2. Portal picks a backend server for them via load balancing — either across all registered servers, or within routing.default_group (falling back through routing.fallback_groups) if groups are configured. Draining or unhealthy servers are skipped. See Configuration.
3. Portal transfers the player to that backend transparently — the player never sees a disconnect.
4. The backend server, using a Client Libraries (or a custom integration over the Socket Protocol), can request further transfers, query player info, look the player up elsewhere on the network, and report draining/health state back to Portal.

Scaling out

A single Portal instance handles one player-facing address and balances across its own registered servers. To run more than one Portal instance in front of the same network of backend servers (e.g. for player-listener capacity or geographic distribution) and still be able to answer "which proxy is this player on", enable Clustering.