Peer-to-Peer

Last updated on August 3, 2026

Overview

AccelByte Gaming Services (AGS) Peer-to-Peer (P2P) lets one player host a game session without deploying a dedicated server. Use this section after you have chosen P2P as the hosting model in Matchmaking.

The shared matchmaking flow is documented in the Matchmaking module. P2P changes what happens after matched players join the game session:

1. AGS Matchmaking creates a game session from a P2P session template.
2. Players receive a game session invitation and join the session.
3. The first joined member becomes the game session leader and P2P host.
4. Other members connect to that host through the AGS P2P transport.
5. The transport attempts direct peer connectivity and falls back to TURN relay when needed.

What P2P Owns

Use the P2P docs for:

• Deciding whether P2P is the right hosting model.
• Creating a P2P session template.
• Setting up Unreal or Unity P2P transport.
• Understanding host election and client connection behavior.
• Configuring TURN, relay fallback, and P2P observability.

Use the Matchmaking docs for:

• Match rulesets.
• Match pools.
• Match ticket creation and cancellation.
• Match found and session invitation callbacks.
• Joining the matched game session.

When to use P2P

Use AGS P2P when your game can run a player-hosted multiplayer session and does not require a dedicated server for game-state authority. P2P is usually a good fit for cooperative games, small party-based matches, custom rooms, or prototypes that need lower server operating cost and simpler server deployment.

Consider AMS dedicated servers instead when your game requires server-authoritative simulation, competitive anti-cheat controls, host migration guarantees, large match sizes, or stable performance that is not affected by one player's device and network quality.

note

P2P still depends on AGS backend services. Game clients use AGS Lobby for signaling, AGS Session to track game sessions, and TURN servers as a relay fallback when a direct peer connection cannot be established.

P2P setup path

Follow this path after choosing P2P in the Matchmaking module:

1. Configure P2P: create a P2P session template.
2. Configure your match pool in Matchmaking to use that P2P session template.
3. Set up P2P transport for your engine:
   • Set up P2P transport using OSS
   • Set up P2P transport using Unity SDK
4. Follow the shared game-code guide:
   • Integrate matchmaking (Unreal)
   • Integrate matchmaking (Unity)
5. In the Connect to the game host section, choose the P2P tab.

Do not start with TURN autoscaling for a first integration. TURN configuration becomes important after the basic two-client connection flow works or when you are preparing production regions and capacity.

What your game must handle

AGS provides session tracking, signaling, STUN checks, TURN relay fallback, and SDK utilities. Your game still owns the gameplay networking model around the P2P connection:

• Decide whether the host is authoritative for gameplay state.
• Handle host disconnects, match cancellation, and reconnect behavior.
• Show UI states for matchmaking, invitation received, joining session, connecting to host, and connection failed.
• Decide whether players can join in progress.
• Test restrictive networks where a TURN relay is required.

Key concepts

The WebRTC, ICE, STUN, and TURN technologies are the basis of AGS P2P.

WebRTC is an open protocol standard to facilitate real-time communication between applications over the internet. WebRTC employs multiple protocols and techniques:

• Interactive Connectivity Establishment (ICE), a technique to get two computers to communicate with each other and to deal with network address translators (NATs), firewalls, and other network barriers.
• ICE uses various techniques such as exchanging network connectivity information via STUN -- Session Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) servers -- as well as relaying network traffic via TURN (Traversal Using Relays around NAT) servers.

AGS hosts these STUN and TURN servers, which are based on Google's COTURN project.

Read more:

• webrtc
• stun-turn-ice
• coturn

Security

When a peer is attempting to connect to another peer, a handshake will be performed via a Signaling Server implemented within AGS Lobby. For security purposes, no public IP address will be exposed and exchanged between the peers.