Session networking
Learn how sessions coordinate network setup, startup, and player connection flow for multiplayer games.
読み終わるまでの所要時間 2 分最終更新 3時間前
Sessions do more than organize players and metadata. They also coordinate the lifecycle of the network connection that supports gameplay. This means session creation and network startup are intentionally separate concerns, which gives you more control over the match flow.
How sessions and networks work together
When a host creates a session, they choose the network type that the session uses from the following options:
WithRelayNetwork()WithDirectNetwork()WithDistributedAuthorityNetwork()
If the host configures the session with one of these options at creation time, the network starts automatically as soon as the session is established. Any player who joins that session is then brought into the same network flow automatically.
If the host doesn't configure a network type up front, the session can exist without starting networking immediately. This allows for pre-match setup, such as character selection, lobby setup, or waiting for all players to be ready. In that case, no network is created for joining players until the host starts it.
When the host is ready, they can start the network explicitly by calling the corresponding API, such as , , or . After the network starts, any subsequent joining player is connected through the same session network.
StartRelayNetworkStartDirectNetworkStartDistributedAuthorityNetworkHost and client behaviors
The session model supports an intentional split between session lifecycle and network lifecycle:
- The host chooses the session's network configuration and controls when to start it.
- Joining players receive the connection information they need from the session.
- The host can delay network startup until gameplay requirements are met.
- Clients can observe the network state through and associated state change events.
session.Network
This separation is useful when your game needs to wait for all players to join, confirm readiness, or complete a pre-match flow before the actual gameplay network begins.
Recommended patterns
Use automatic network startup when your experience is ready to begin immediately after the session is created. Use delayed startup when you need to control matchmaking, player readiness, or game setup before connecting players.
In general, use Relay or Distributed Authority for internet-based games where you want to protect player IP addresses and simplify NAT traversal. Use direct networking only when your game has a specific reason to expose direct peer connectivity and you understand the networking constraints.
For more information, refer to Network connection management and Session events.