Networking: choose HTTP, WebSocket or game multiplayer
Choose a protocol, separate requests from game state and verify a local connection.
Choose by task
A networking API transfers data; the application defines game rules, authorization and durable results. Begin with one complete exchange between two participants, then add gameplay.
| Task | API | Your responsibility |
|---|---|---|
| Fetch JSON, submit data, download a file | HttpRequest | Validate startup, transport, HTTP status and payload |
| Manage an HTTP connection and read body chunks | HttpClient | Poll, states, body framing, deadline and cleanup |
| Maintain a message-based connection | WebSocketPeer | Message format, limits, reconnect and closing |
| RPC and server-owned game state over UDP | ENetMultiplayerPeer + SceneMultiplayer | Invocation rights, sender/payload validation, connect/disconnect |
| Peer-to-peer exchange through WebRTC | WebRtcPeerConnection / WebRtcDataChannel | A working implementation, signaling, ICE and target-platform tests |
HTTP and WebSocket do not automatically synchronize Entity instances. Low-level WebSocketPeer is not a SceneMultiplayer RPC connection; that design requires an appropriate MultiplayerPeer. A Go JSON/HTTP server does not become a game-RPC server just by using the same address/port.
Verify one exchange
- For data requests, run the HTTP fixture and JSON client. It distinguishes 404, malformed JSON and transfer failure.
- For a persistent connection, run WebSocket echo: a message returns unchanged, followed by closing.
- For game state, run the ENet lobby: a client requests readiness, the server validates it and distributes the resulting state.
- Before WebRTC, run the implementation check. A C# class does not prove a working channel.
Local examples use 127.0.0.1 and do not bind a server to every interface. 127.0.0.1 always means the current machine: on another computer it does not address your server. Port 0 lets the OS choose a free fixture port; the client receives the actual LocalPort.
For a deployed ENet server, separately configure bind address, UDP port and reachable routing. A TCP rule does not replace UDP. CreateServer does not create NAT traversal, relay, discovery or matchmaking. Use HTTPS/WSS and certificate verification for protected HTTP/WebSocket connections.
Separate a request from confirmed state
A client submits intent: ready, a button press or a pickup request. The server checks sender, game phase, validity and replay. Clients display confirmed state. Successful sending means the transport accepted data, not that the gameplay result was saved.
A peer ID belongs to a network session, not a persistent account identity. Local object IDs and Resource references are not universal network identities either. Define message formats and update rules explicitly; identical packets can mean different actions in different game phases.
Verified scope
HTTP/JSON, WebSocket/WSS and ENet use real local connections. The lobby runs as three independent MultiplayerApi instances in one process and as a host plus two clients in three engine processes. Requests, snapshots, spoofing rejection, disconnect and reconnect are checked.
This does not cover separate machines, WAN/NAT, browser export, mobile permissions, performance or production abuse resistance. A separate diagnostic on the current Windows fixture did not complete IPv6-loopback or localhost TCP connections within its deadline, while IPv4 worked. The OS/implementation cause is not established. A local IPv4 test does not establish every address family.