Valve впервые за 4 года обновил GameNetworkingSockets — что нового в 1.5
Первый релиз GameNetworkingSockets за почти 4 года. Поменялась семантика SendMessages, добавились ECN и jitter stats, появились Rust bindings. Разбираем, что в нём.
Новости Tproger
Valve впервые с лета 2022 года выложила тег GameNetworkingSockets — релиз 1.5. Накопленный за почти четыре года хвост — около 350 коммитов с прошлого тега: поменялась семантика SendMessages (нужно ревизовать места, которые ничего не делают с её результатом), появились ECN и jitter-метрики, ETW-диагностика на Windows, фиксы race-багов в P2P через WebRTC ICE и community-биндинги для Rust. Если про эту библиотеку слышите впервые — на ней работают Counter-Strike, Dota 2 и десятки сторонних проектов, использующих Steam Datagram Relay.
GameNetworkingSockets (GNS) — это open-source транспортный слой для игр от Valve. UDP-сокеты с надёжной доставкой, шифрованием end-to-end, congestion control, NAT traversal через ICE, retry-логикой поверх ненадёжной сети. По устройству ближе всего к QUIC — UDP в основе, поверх свой надёжный канал, шифрование, фрагментация. Но это не QUIC: формат пакетов и хэндшейк свои, совместимости с RFC 9000 нет. Когда Valve открыла исходники в 2018 году, у инди-разработчиков и небольших студий появился рабочий движок сетевой части без необходимости заказывать его за миллионы долларов или писать самим с нуля.
С тех пор библиотеку взяли в самые разные продукты — от шутеров до симуляторов и до RPG. Major-тег 1.4.0 вышел в январе 2022 года, патч-релиз 1.4.1 — в июне 2022. С тех пор в репозитории шла обычная разработка — около 350 коммитов в master с фиксами и улучшениями, — но нового тега не было. 28 апреля 2026 года Valve собрала весь этот хвост в релиз 1.5 и подытожила, что именно изменилось.
Ключевые выводы
v1.5.0 — первый тег за почти 4 года. Major-тег 1.4.0 вышел в январе 2022, патч 1.4.1 — в июне 2022. Накопленный хвост — около 350 коммитов в master с прошлого тега.
Поменялась семантика SendMessages. Раньше функция возвращала единый код, по которому невозможно было понять, какие из сообщений ушли. Теперь каждое сообщение получает свой результат, и интерфейс облегчает retry. Старый код, который игнорировал результат и работал как «отправь и забудь», нужно пересмотреть.
Новые конфиги: Explicit Congestion Notification (ECN), статистика jitter, IPLocalHost_AllowWithoutAuth и ещё несколько. Помогают тюнинговать поведение в стрессовых сетях и тестовых окружениях.
Native ICE-клиент по-прежнему в beta. Race-баги, ведущие к hang, починили; для production-P2P пока всё равно WebRTC ICE.
Появились первые Rust bindings — community-вклад, не официально поддерживаемый Valve, но рабочая отправная точка для Rust-проектов.
Что такое GameNetworkingSockets и кто на нём работает
GameNetworkingSockets — это библиотека сетевого транспорта, открытая Valve в 2018 году. По смыслу она ближе всего к QUIC: UDP в основе, поверх — собственный надёжный канал, шифрование, контроль перегрузки, фрагментация. Главное отличие — ориентация на игровой трафик: маленькие частые сообщения, тонкая конфигурация ретраев, поддержка ненадёжной доставки рядом с надёжной (можно выбрать на каждое сообщение).
Использует библиотеку прежде всего сама Valve: на ней работают Counter-Strike, Dota 2 и любой другой мультиплеер из Steam, который ходит через Steam Datagram Relay (SDR) — собственную сеть Valve, агрегирующую трафик через быстрые узлы поближе к игроку. Кроме Valve, библиотеку взяли разные инди- и middleware-проекты, плюс она встроена как дополнительный backend в несколько игровых движков.
У GNS есть два режима. Первый — клиент-сервер по обычному IP, без участия Steam-сети. Второй — P2P, через ICE для NAT traversal. P2P-режим требует внешнего signaling-сервера для обмена ICE-кандидатами между пирами; пример Valve поставляет в репозитории.
Что нового в 1.5
API: новая семантика SendMessages, плоский C API для Messages
Главное изменение в API — поведение ISteamNetworkingSockets::SendMessages при ошибках. Раньше функция возвращала единый код, который не давал понять, какие из сообщений ушли, а какие нет. Теперь каждое сообщение получает свой результат, а интерфейс облегчает retry — можно прозрачно переотправить только упавшие, не дублируя успешные. Если у вас в коде есть обёртка «отправил пачку — получил ОК или нет», её надо переписать под новый паттерн, иначе при сбоях часть сообщений просто потеряется.
Добавлен flat C API для ISteamNetworkingMessages — это режим, где сокеты привязываются не к connection-у, а к идентичности игрока, и отправка идёт по принципу «отправь пользователю X». Раньше этот режим был доступен только из C++. Теперь можно дёргать его и из C, и из любого языка с C FFI без C++-обёртки — что особенно актуально для Rust-, Go- и Python-биндингов.
Появилась хук-функция SteamNetworkingSockets_SetServiceThreadInitCallback — для тех, кто хочет подкрутить поведение сервисного потока (приоритет, имя, привязка к ядру) до того, как библиотека начнёт обрабатывать пакеты.
Надёжность и наблюдаемость
На уровне пакетов и очереди сообщений библиотека теперь автоматически корректирует часть out-of-order ситуаций — раньше эти случаи выливались в reorder-events для прикладного кода, и каждый разработчик разбирался с ними сам. Не идеальное решение для всех сценариев, но для игрового трафика — обычно то, что нужно по умолчанию.
Из новых конфигов и метрик:
- ECN (Explicit Congestion Notification) — поддержка пометок в IP-заголовке, чтобы роутеры могли сигнализировать о перегрузке без потери пакетов.
- Jitter stats — статистика разброса времени доставки, видимая через стандартные accessor-ы. Полезно для тонкой настройки буферов и плавности геймплея.
IPLocalHost_AllowWithoutAuth— режим без аутентификации для localhost-соединений, удобен в тестовых сборках, dedicated-серверах локальной отладки и CI.- ETW (Event Tracing for Windows) — диагностические события, видимые в Windows Performance Analyzer и аналогах.
P2P: ICE-клиенты, race-баги
P2P-стек получил серию точечных фиксов. В WebRTC ICE-клиенте, который Valve использует как основной для P2P, починили race-баги, которые приводили к hang при определённых таймингах рукопожатия. В нативном ICE-клиенте — собственной имплементации ICE-стека Valve, которая развивается параллельно ICE из WebRTC, исправили несколько багов, но он по-прежнему помечен как beta — для production пока рекомендуют WebRTC ICE.
Пример сигнального сервера в репозитории переписан с нуля на Python — раньше он жил на C++ и имел набор багов, которые мешали запустить локальный P2P-тест из коробки. Сейчас пример работает «как описано» и заодно проверяется в CI: P2P-сценарии добавили в авто-тесты, что для самоподдерживающейся кодовой базы серьёзный шаг.
Rust bindings, CMake/vcpkg, протобафы
В релиз попали первые официальные Rust bindings — но с дисклеймером community contribution: их пишет и поддерживает не Valve, а сторонние мейнтейнеры. Если планируете сетевой стек на Rust поверх GNS — подключите биндинг как зависимость, но будьте готовы к тому, что приоритет фиксов и обновлений отличается от основной библиотеки.
Интеграция с CMake и vcpkg существенно упрощена — собрать GNS без сторонних рецептов теперь реально на обычной машине. Параллельно починили совместимость с новыми версиями protobuf и abseil — последняя регулярная боль для тех, кто строил на vcpkg или conan.
Почему 4 года тишины
Valve в release notes причину не комментирует. Видимая динамика — около 600 коммитов в master за этот период, регулярные мерж-реквесты от внешних контрибьюторов, активное реагирование на issue. Пакетный релиз делается, по всей видимости, по другому критерию — когда внутреннее использование в продуктах требует фиксированной версии для интеграции.
Для пользователей библиотеки это означало одно из двух: либо собирать сборку из master и брать на себя риск сломанных интерфейсов, либо сидеть на 1.4, не получая четырёх лет улучшений. Релиз 1.5 закрывает обе дороги: можно зафиксироваться на стабильном теге и получить весь хвост.
Стоит ли переходить на 1.5
Если у вас 1.4 в продакшене:
- Тщательно проверьте код вокруг
SendMessages— теперь по каждому сообщению есть свой результат, и старый «отправь и забудь» нужно дополнить логикой ретраев. - Прогоните регрессионный тест P2P, если используете — race-баги в WebRTC ICE и нативном ICE затрагивали реальные сценарии и могли проявляться раз в N подключений.
- Подключите ECN и jitter stats к телеметрии — за 4 года накопилось чем мерить качество соединения, грех не воспользоваться.
- Если в ваших сборках болела совместимость с протобафом или abseil — берите 1.5: эти места починили.
Если выбираете между GNS и альтернативами для нового проекта — релиз 1.5 не меняет принципиально позиционирование. GNS остаётся хорошим выбором, когда нужен стабильный, проверенный в Counter-Strike транспорт с готовым P2P для NAT traversal. Для проектов, где важно глубже интегрироваться с QUIC, WebTransport или WebRTC напрямую, существуют более специализированные стеки. Между GNS и более минималистичными ENet, kcp, RakNet выбор зависит от потребностей: GNS даёт из коробки больше фич (ICE, шифрование, контроль перегрузки), ценой большего C++-кода и зависимостей; ENet и kcp компактнее и быстрее интегрируются.
Часто задаваемые вопросы
Я использую GNS в инди-проекте на 1.4. Можно сразу взять 1.5?
Да, но прогоните тесты вокруг SendMessages — это самое заметное breaking-изменение поведения. Остальные изменения в основном accretive: новые конфиги, новые метрики, доп. C API. Если вы не строили хитрых ассертов на старое поведение SendMessages, релиз должен сесть без сюрпризов.
Что такое Steam Datagram Relay (SDR) и связан ли он с GNS?
SDR — это инфраструктура Valve, которая агрегирует игровой трафик через свои узлы по миру: клиент шлёт пакеты в ближайшую точку SDR, дальше Valve гоняет их по своему быстрому бэкбону, потом снова через SDR — до сервера. GNS — это open-source транспортный слой, который умеет ходить как через SDR (если вы интегрированы со Steam), так и через обычные UDP-сокеты. SDR работает только для Steam-игр, GNS — для любых.
Rust bindings — насколько они production-ready?
Они помечены как community contribution, поэтому зависят от внешнего мейнтейнера. Для прототипирования и pet-проектов — ок, для production — нужно либо самим участвовать в поддержке, либо иметь fallback-план на случай, если биндинг отстанет от основной библиотеки. Это нормальная ситуация для community-bindings, но смотреть на это глазами «вот есть стабильный API за подписью Valve» преждевременно.
Когда ждать 1.6?
Неизвестно. Темп релизов у Valve в этом репозитории явно больший, чем годовой — и судя по 4-летнему хвосту, выпуск тега не привязан к календарю. Безопасно ориентироваться на коммиты в master: если вам нужна свежая фича — она там обычно есть, релиз — это про фиксацию для downstream-пользователей.
Заменит ли это QUIC или WebRTC для игр?
Не заменяет, а сосуществует. У QUIC и WebRTC своя специфика и свои бэкенды; у GNS — игровая. Для браузерных игр имеет смысл оставаться на WebRTC. Для нативных мультиплеерных движков, не привязанных к браузеру, GNS — рабочий выбор, и в 1.5 он становится чуть менее «вещь в себе».
Выводы
GameNetworkingSockets 1.5 — это спокойный пакетный релиз: четыре года накопленных улучшений, без масштабных переписываний интерфейсов. Главное API-изменение — семантика SendMessages, и это та правка, которую разработчики на 1.4 пропустить не смогут. Всё остальное — про observability, P2P-стабильность и удобство сборки.
Сам факт, что Valve собрала тег после такой паузы, — хороший сигнал: библиотеку используют достаточно, чтобы стабильный артефакт имел смысл. Для маленьких студий, у которых нет сил тащить master из репозитория каждый раз, это означает возможность снова жить на стабильной версии без четырёхлетнего отставания.
Источники: релиз v1.5.0 на GitHub, репозиторий и документация, обзор у Phoronix.
