Pixockets: как мы написали собственную сетевую библиотеку для игрового сервера29.04.2020 17:49

Привет! На связи Станислав Яблонский, Lead Server Developer из Pixonic.

Когда я только пришел в Pixonic, наши игровые сервера представляли собой приложения на основе Photon Realtime SDK: многофункционального, но весьма тяжелого фреймворка. Решение это, казалось бы, должно было упростить работу с сервером. Так оно и было ― до определенного момента.

Photon Realtime привязывал нас к себе тем, что приходилось использовать его для обмена данными между игроками и сервером, ―, а также привязывал к ОС Windows, поскольку может работать только на ней. Это накладывало на нас ограничения как с точки зрения runtime (среды исполнения): нельзя было изменить многие важные настройки виртуальной машины .NET, ― так и операционной системы. Мы привыкли работать с Linux-серверами, а не Windows. Кроме того, они нам обходились дешевле.

Также использование Photon било по производительности как на сервере, так и на клиенте, а при профилировании образовывалась приличная нагрузка на сборщик мусора и большое количество boxing/unboxing.

Короче говоря, решение с Photon Realtime было далеко от оптимального для нас, и давно надо было что-то с этим делать ―, но всегда находились более срочные задачи, и до решения проблем с сервером руки банально не доходили.

Так как мне было интересно не только решить проблему, но и лучше разобраться в работе сети, я решил взять инициативу в свои руки и попробовать написать библиотеку самостоятельно. Но, сами понимаете, дома ― дом, на работе ― работа, в результате время на разработку библиотеки находилось только в транспорте. Однако это не помешало довести идею до реализации.

Что из этого вышло ― читайте дальше.

Идеология библиотеки

Поскольку мы занимаемся разработкой онлайн-игр, нам очень важно работать без пауз, поэтому главным требованием к библиотеке стали низкие накладные расходы. Для нас это, прежде всего, низкая нагрузка на сборщик мусора. Чтобы ее добиться, я старался избегать аллокаций, а в случаях, когда этого добиться было сложно или не получалось вовсе, мы делали пулы (для байтовых буферов, состояний соединений, заголовков и т. д.).

Для простоты и удобства поддержки и сборки мы стали использовать только C# и системные сокеты. Кроме того, важно было вписываться в бюджет времени на кадр, ведь данные с сервера должны были приходить вовремя. Поэтому я старался уменьшить время выполнения операций, пусть даже ценой некоторой неоптимальности: то есть, местами стоило заменить быстрые и отчасти более сложные алгоритмы и структуры данных на более простые и предсказуемые. Например, мы не использовали lock-free очереди, так как они создавали нагрузку на сборщик мусора.

Типично для мультиплеерных шутеров, данные у нас пересылаются по UDP. Еще поверх него была добавлена фрагментация и сборка пакетов для пересылки данных большего объема, чем размер фрейма, а также надежная доставка за счет пересылки и установка соединения.

UDP-фрейм в нашей библиотеке по умолчанию занимает 1200 байт. Пакеты такого размера должны передаваться в современных сетях с достаточно низким риском фрагментации, так как MTU в большинстве современных сетей выше этого значения. В то же время обычно этого объема достаточно, чтобы туда поместились изменения, которые нужно послать игроку после очередного тика (обновления состояния) в игре.

Архитектура

В своей библиотеке мы используем двухслойный сокет:

Первый слой отвечает за работу с системными вызовами и обеспечивает более удобное API для следующего уровня;
На втором слое идет непосредственно работа с сессией, фрагментация/сборка пакетов, их пересылка и т. п.

Класс для работы с подключением, в свою очередь, тоже разделен на два уровня:

Нижний уровень (SockBase) отвечает за посылку и прием данных по UDP. Он представляет собой тонкую обертку над системным объектом сокета.
Верхний уровень (SmartSock) обеспечивает дополнительную функциональность поверх UDP. Разрезание и склеивание пакетов, пересылка не дошедших данных, отброс дубликатов ― все это зона его ответственности.

Нижний уровень делится еще на два класса: BareSock и ThreadSock.

BareSock работает в том же потоке, откуда произошел вызов, передавая и принимая данные в неблокирующем режиме.
ThreadSock складывает пакеты в очереди и таким образом создает отдельные потоки для отправки и приема данных. При обращении к нему происходит только одна операция: добавления или удаления данных из очереди.

BareSock чаще используется для работы с клиентом, ThreadSock ― с сервером.

Особенности работы

Низкоуровневых сокетов я написал также два вида:

Первый ― синхронный однопоточный. В нем мы получаем минимальные накладные расходы по памяти и процессору, но при этом системные вызовы происходят прямо при обращении к сокету. Это минимизирует накладные расходы в целом (не нужно использовать очереди и дополнительные буферы), но сам вызов может занять больше времени, чем взятие элемента из очереди.
Второй ― асинхронный с отдельными потоками для чтения и записи. В этом случае мы получаем дополнительные накладные расходы на очередь, синхронизацию и время отправки/приема (в пределах нескольких миллисекунд), так как в момент обращения к сокету тред чтения или записи ставится на паузу.

Мы также пробовали использовать SocketAsyncEventArgs ― пожалуй, самое современное сетевое API в .NET из тех, что я знаю. Но оказалось, для UDP оно, вероятно, не подходит: TCP-стек через него работает нормально, но UDP выдает ошибки о получении странно обрезанных фреймов и даже падения внутри .NET ― как если бы повреждалась память в нативной части виртуальной машины. Примеров работы подобной схемы я не нашел.

Еще одной важной особенностью нашей библиотеки является пониженная потеря данных. У нас сложилось впечатление, что для избавления от дубликатов многие библиотеки отбрасывают старые пакеты с данными, в чем впоследствии мы убедились на собственном опыте. Конечно, такая реализация намного проще, ведь в ее случае достаточно одного счетчика с номером последнего пришедшего фрейма, но нас она не очень-то устраивала. Поэтому в Pixockets для отсеивания дубликатов используется циклический буфер из номеров последних фреймов: вновь пришедшие номера перезаписываются вместо старых, и поиск дубликатов происходит среди последних пришедших фреймов.

Таким образом, если пакет был послан до текущего фрейма, а пришел после, он все равно дойдет до адресата. Это может сильно выручить, например, в случае интерполяции позиций. В таком случае у нас будет более полная история.

Структура пакета данных

Данные в библиотеке передаются в следующем виде:

В начале пакета идет заголовок:

Он начинается с размера пакета, который, в свою очередь, ограничен 64 килобайтами.
За размером следует байт с флагами. От их наличия зависит интерпретация остальной части заголовка.
Далее ― идентификатор сессии, или соединения.

При наличии соответствующих флагов далее мы получаем:

Если установлен флаг с номером пакета по очереди, после идентификатора сессии передается номер пакета.
Следом за ним ― также в случае установленного флага ― количество подтверждаемых пакетов и их номера.

В конце заголовка идет информация о фрагменте:

идентификатор последовательности фрагментов, который необходим для того, чтобы различать фрагменты разных сообщений;
порядковый номер фрагмента;
общее количество фрагментов в сообщении.

Информация о фрагменте также требует установки соответствующего флага.

Библиотека написана. Что дальше?

Для того, чтобы иметь более точную синхронную информацию о соединении, позже мы организовали явное соединение. Это помогло нам ясно осознавать ситуации, когда одна сторона думает, что соединение установлено и не прерывалось, а другая ― что прервалось.

В первой версии Pixockets этого не было: клиенту не нужно было звать метод Connect (host, port) ― он просто начинал передавать данные по известному адресу и порту. Тогда сервер вызывал метод Listen (port) и начинал получать данные с определенного адреса. Данные о сессии инициализировались по факту приема/передачи пакета.

Теперь для установления соединения стало необходимо «рукопожатие» ― обмен специально сформированными пакетами, ―, а клиент обязан вызвать Connect.

Кроме того, один из моих коллег сделал форк библиотеки, уделив больше внимания сетевой безопасности, а также добавив некоторые фичи, такие как возможность восстановления соединения прямо внутри сокета: так, при переключении между Wi-Fi и 4G соединение теперь восстанавливается автоматически. Но об этом мы еще расскажем позже.

Тестирование

Само собой, для библиотеки мы написали юнит-тесты: ими проверяются все основные способы установления соединения, отправки и приема данных, фрагментация и сборка пакетов, различные аномалии при отправке и получении данных ― такие как дубликация, пропажа, несоответствие порядка отправки и получения. Для первоначальной проверки работоспособности я написал специальные тестовые приложения для интеграционного тестирования: пинг-клиент, пинг-сервер и приложение, синхронизирующее по сети положение, цвет и количество цветных кружков на экране.

После того, как тестовые приложения доказали работоспособность нашей библиотеки, мы приступили к сравнению ее с другими библиотеками: с нашим старым Photon Realtime и с UDP-библиотекой LiteNetLib 0.7.

Мы тестировали упрощенный вариант гейм-сервера, который просто собирает ввод от игроков и отсылает обратно «склеенный» результат. Мы взяли 500 игроков в комнатах по 6 человек, частота обновления 30 раз в секунду.

Нагрузка на сборщик мусора и потребление процессора оказывались ниже в случае Pixockets, как и процент пропавших пакетов ― видимо, за счет того, что, в отличие от остальных исполнений UDP, мы не игнорируем опоздавшие пакеты.

После того, как мы получили подтверждение преимущества нашего решения в синтетических тестах, следующим шагом было принято обкатать библиотеку на реальном проекте.

На тот момент в выбранном нами проекте клиенты и игровые сервера синхронизировались через Photon Server. Я добавил поддержку Pixockets на клиент и на сервер, сделав возможность управления выбором протокола с матчмейкинг-сервера ― того самого, которому клиенты отправляют запрос на вход в игру.

В какой-то период клиенты играли одновременно по обоим протоколам, а мы в это время собирали статистику, как у них обстоят дела. По окончании сбора статистики оказалось, что результаты не отличаются от синтетических тестов: нагрузка на сборщик мусора и процессор снизилась, потеря пакетов тоже. Заодно и пинг стал немного ниже. Поэтому следующая версия игры вышла уже полностью на Pixockets без использования Photon Realtime SDK.

Планы на будущее

Теперь мы хотим внедрить в библиотеку следующие фичи:

Упрощенное подключение: сейчас оно работает не совсем оптимально, и после вызова Connect на клиенте нужно вызывать Read до изменения статуса соединения;
Явное отключение: на данный момент отключение на другой стороне происходит только по таймеру;
Встроенные пинги для поддержания жизнеспособности подключения;
Автоматическое определение оптимального размера фрейма (сейчас используется просто константа).

Посмотреть и поучаствовать в дальнейшей разработке Pixockets можно по адресу репозитория: github.com/pixonic/pixockets