Сеть: выбрать HTTP, WebSocket или игровой мультиплеер
Как выбрать протокол, разделить запрос и игровое состояние и проверить локальное соединение.
Выбрать по задаче
Сетевой API передаёт данные; правила игры, авторизацию и сохранение результата задаёт приложение. Начните с одного законченного обмена между двумя участниками, затем добавляйте игровой код.
| Задача | API | Что нужно сделать самостоятельно |
|---|---|---|
| Получить JSON, отправить форму, скачать файл | HttpRequest | Проверить запуск, транспорт, HTTP-статус и содержимое |
| Управлять HTTP-подключением и читать тело частями | HttpClient | Poll, состояния, границы тела, срок ожидания и очистка |
| Держать соединение с обменом сообщениями | WebSocketPeer | Формат сообщений, лимиты, переподключение и обработка закрытия |
| RPC и серверное игровое состояние поверх UDP | ENetMultiplayerPeer + SceneMultiplayer | Права вызова, проверка отправителя/данных, подключение и отключение |
| Peer-to-peer обмен через WebRTC | WebRtcPeerConnection / WebRtcDataChannel | Рабочая реализация, signaling, ICE и тест целевой платформы |
HTTP и WebSocket не превращают данные в синхронизированные Entity автоматически. Низкоуровневый WebSocketPeer не является высокоуровневым RPC-соединением SceneMultiplayer; для такой схемы нужен соответствующий MultiplayerPeer. Сервер JSON/HTTP на Go тоже не становится сервером игровых RPC только из-за совпадения адреса/порта.
Проверить один обмен
- Для запроса данных запустите HTTP-стенд и JSON-клиент. Он различает 404, ошибку JSON и ошибку передачи.
- Для постоянного соединения запустите WebSocket echo: сообщение возвращается без изменения, затем проходит закрытие.
- Для игрового состояния запустите лобби ENet: клиент просит изменить готовность, сервер проверяет запрос и рассылает итоговое состояние.
- Перед WebRTC выполните проверку реализации. Наличие C#-класса не доказывает рабочий канал.
Локальные примеры используют 127.0.0.1 и не открывают сервер на всех интерфейсах. Адрес 127.0.0.1 всегда означает текущую машину: на другом компьютере он не указывает на ваш сервер. Выбор порта 0 в стендах поручает ОС выдать свободный порт; клиент получает фактический LocalPort.
Для размещённого ENet-сервера отдельно настройте адрес привязки, UDP-порт и доступность маршрута. TCP-правило не заменяет UDP. NAT, relay, обнаружение серверов и подбор игроков не создаются вызовом CreateServer. Для защищённых HTTP/WebSocket используйте HTTPS/WSS и проверку сертификата.
Разделить запрос и подтверждённое состояние
Клиент передаёт намерение: «готов», «нажал кнопку», «хочу подобрать предмет». Сервер проверяет отправителя, фазу игры, допустимость и повтор запроса. Клиент отображает подтверждённое состояние. Успешный вызов отправки означает принятие данных транспортом, а не сохранённый игровой результат.
Peer ID живёт в сетевой сессии и не заменяет постоянный ID учётной записи. Номера локальных объектов и ссылки на Resource также не являются универсальными сетевыми идентификаторами. Формат игровых сообщений и правила обновлений задавайте явно; одинаковые пакеты могут означать разные действия в разных фазах игры.
Что проверено
HTTP/JSON, WebSocket/WSS и ENet проверяются настоящими локальными соединениями. Лобби исполняется как три независимых MultiplayerApi в одном процессе и как сервер с двумя клиентами в трёх процессах движка. Проверены запросы, снимки состояния, запрет подмены, отключение и повторное подключение.
Это не проверка разных машин, WAN/NAT, браузерного экспорта, мобильных разрешений, производительности или готовой защиты от злоупотреблений. В отдельной диагностике текущего Windows-стенда TCP-подключение к IPv6 loopback и через localhost не завершилось за отведённое время; IPv4 работает. Причина на уровне ОС/реализации ещё не установлена. Не принимайте локальный IPv4-тест за подтверждение всех адресных семейств.