Developer Workshop | Сетевое Сжатие И Контроль Перегрузки

[ILeora]

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

Основа сетевого кода Warframe довольно развитая, она относится к временам Dark Sector'а и мы связали много игр с ней. Мне пришлось серьёзно пересмотреть её, чтобы внести в The Darkness 2 (нужно было, чтобы она соответствовала техническим требованиям X360/PS3). Тогда казалось, что основа в хорошей форме, ещё до старта Warframe. Прошло несколько лет, и, не смотря на то, что мы внесли несколько серьёзных изменений в течение времени (в частности для Warframe), становится всё более очевидно, что то, что было хорошо в 2012 году уже не работает в 2014. Другая же проблема в том, что игра Warframe просто намного больше, чем The Darknes 2 (D2). Приведу простой пример: среднестатистический уровень Warframe содержит как минимум в 10 раз больше воспроизведённых объектов, чем средняя многопользовательская карта D2. Как уже говорилось выше, мы внесли несколько изменений, улучшивших ситуацию, но было предельно ясно, что рано или поздно нам придётся попробовать что-то более радикальное. 

Мне бы хотелось кратко описать то, над чем я работал больше всего за последние несколько недель. Большая часть моих усилий была сосредоточена на двух направлениях: сетевое сжатие и контроль насыщения.

 

 

Сетевое сжатие

 

Просто для того, чтобы дать вам лучше понять с чем мы боремся - сервер отсылает обновления через сеть с определённой частотой, предположим 3 раз в секунду. Также предположим, что мы создали 30 единиц NPC (не такое уж и необычное количество для миссии в Warframe). Даже если мы используем лишь 20 байт на единицу NPC это будет 30*20*30=18000 байт в секунду на одних лишь NPC! Добавим игроков (они обычно обходятся гораздо дороже), умножим на 3 (3 клиента) и наше 512кб/с (=64КБ/с) соединение с сервером потеряно. 20 байт не хватит даже чтобы написать письмо домой, хотя, едва ли этого хватит для полного описания расположения и изменений данных о, к примеру, месте для здоровья, анимации, информации об уроне? Что делают игры, чтобы обойти эту проблему? Во-первых - мы жульничаем. 

Мы не отсылаем информацию, если считаем, что можем обойтись без неё (к примеру, NPC вне поля зрения), мы не описываем всё в полной мере, мы разделяем свойства на несколько групп (критические/важные/нормальные/косметические) и так далее - у каждого разработчика есть свой багаж таких фишек. Кроме того, данные при передаче обычно сжимаются. Улучшение этого сжатия стало важным результатом, но сперва давайте рассмотрим некоторую информацию о сетевом сжатии и узнаем как это относится к Warframe.

Сетевое сжатие, само по себе, интересная проблема, игровые пакеты, как правило, довольно малы (несколько сотен байт), таким образом алгоритмы, разработанные для работы с мегабайтами данных не в полной мере подходят для сетевого сжатия. Мы не можем позволить себе затратить больше нескольких байт на заголовок, к примеру. Длительное время в Warframe использовалось LZF сжатие для всего сетевого трафика. Оно невероятно быстрое, легкодоступное на всех платформах, об этом мы и заботились (я говорю не только о различиях в аппаратной части, это касается и обслуживания нашего сервера Станций). В целом это обеспечивает достаточный уровень сжатия. Эффективность колеблется в зависимости от типа миссии, но в самых наших затратных случаях (Выживания) мы имеем что-то около 1.24:1 (80%). Другими словами, буфер сжатия составляет 80% от несжатой единицы. Приняв во внимание все ограничения, что я упомянул ранее, это кажется не таким уж и плохим результатом, но мы полагаем, что его можно улучшить.

Я немного поэкспериментировал с другими алгоритмами сжатия, но оказалось сложно значительно превысить результат LZF. К счастью, я узнал, что ребята из RAD Game Tools запустили свою сеть и свою библиотеку сжатия данных. Вам может быть незнакомо название RAD, но я на 100% уверен в том, что вы играли в игру, которая содержала их технологию. Это те люди, что стоят за Bink movie codec и Miles Sound System (и за некоторыми другими известными программами-посредниками). Ребята из RAD, в основном, это группа гениев кода, у них обычно лишь несколько программистов работают над одним проектом, но эти программисты являются одними из ведущих экспертов в своей области. Мы попросили их сделать оценку, провести несколько быстрых тестов и результаты были довольно многообещающими. Чтобы их алгоритм сжатия работал, в первую очередь нужно изучить ваши данные, используя реальные образцы, взятые из игры. Я собрал более 100Мб сетевого трафика Warframe чтобы создать окончательный "словарь". Помните 1.25:1 (80%), что я упоминал? 

С нашей новой системой сжатия нам удалось достичь 1.8:1 (55%) в некоторых сценариях. Что ж, если ранее вы играли в длительные совместные Выживания, используя для работы данные объёмом 80% от оригинала, то теперь мы сжали эти данные более чем на 55% от оригинального размера. Прирост варьируется в зависимости от типов миссий, но способ, который я пробовал, показывает, что он наибольший в самых сложных ситуациях (в целом, сжатие не так важно, если мы не посылаем слишком больших пакетов данных). Должен сказать, что новая система сжатия показала себя гораздо лучше, чем старая в каждом сценарии, что я проверил. Самый худший результат, что я видел был около 1.4:1. 

TL;DR версия: Warframe использует новую систему сетевого сжатия, передавая значительно меньше данных.

 

 

Контроль перегрузки

 

Как вы уже заметили, мы стараемся достичь как можно меньшего объёма передачи данных. Для этого есть очень важная причина - мы не хотим чтобы ваш сетевой лимит достиг предела пропускной способности. Как вы, вероятно, знаете, есть 2 основных сетевых протокола - TCP и UDP. Не вдаваясь сильно в детали, TCP на самом деле значительно сложнее и делает много вещей в фоновом режиме, вы можете приравнять его к надёжному и безопасному семейному фургону. В отличие от него, UDP это голый скелет, он позволяет вам отправлять и получать данные, обладает некоторой базовой поддержкой контрольных сумм, но вот что, думайте об этом как о машине Формулы 1. Большинство шутеров, в их числе и Warframe, используют UDP для общения. Если это используется правильно, то это довольно эффективно, но требует заботы о надёжности, порядке и не в последнюю очередь - загруженности. Если мы прикажем ему передать слишком много данных, то UDP попытается это сделать, но рано или поздно ваше соединение начнёт отставать и/или терять пакеты. 

TCP имеет встроенный механизм контроля за перегрузками, с UDP вы предоставлены сами себе. Основная идея состоит в том, чтобы "отступить" когда мы фиксируем снижение качества нашего соединения, а затем возможно увеличить количество передаваемых данных, когда это покажется нам безопасным. Это легко на бумаге, но это очень коварная проблема (просто скажу, что Линукс обладает не менее, чем 10 различными алгоритмами контроля перегрузок, каждый со своими недостатками и преимуществами).

Warframe использует немного модифицированную версию алгоритма The Darkness 2 и хоть он выполняет свою работу, он не очень умный (хей, я писал его код, я имею право так говорить). Последние несколько недель я экспериментировал со множеством различных подходов, в основном обнаружил, что они прекрасно не работают в нашей ситуации. Проблема, вновь, сводится к тому факту, что игры сильно отличаются от большинства приложений. "Мейнстримовые" алгоритмы работают с большим количеством разнообразных ситуаций, мы можем улучшить их, если будем заботиться только он нашем конкретном случае. Управление перегрузкой сводится к тому, чтобы вычислить предел нашей сети и пытаться передавать столько данных, сколько это возможно, только не слишком много. Обычных алгоритмов контроля перегрузок хватает, когда нам нужно скачать файл, к примеру, трафик довольно устойчив, а если нам недостаточно пропускной способности, то это просто займёт немного больше времени. Мы не можем позволить себе такую роскошь в играх. 

Если информация об уроне будет приходить на 10 секунд позднее, то это "сломает" погружение. Трафик в играх идёт очередями, он редко бывает устойчив, у нас не слишком много времени, чтобы вычислить наши пределы, нам нужно реагировать мгновенно. Время, затраченное на эксперименты не пропало даром, хотя, изучив недостатки и преимущества различных подходов я стал немного Франкенштейном алгоритма, что, кажется, дало неплохие результаты. Это был лишь первый шаг, мне нужно изменить кое-что в дальнейшем так, чтобы это работало более корректно, чем с одним клиентом (мы хотим распределить нагрузку по клиентам равномерно, а не так чтобы один взял 90%,к примеру), но это прошло довольно быстро оттуда. В случае, если вы заинтересованы, (не очень) хороший график покажет пропускную способность распределённую на 2-х клиентов (это малость грубовато, так как было предназначено лишь для внутренних целей). 

Я искусственно ограничил пропускную способность хоста 30КБ/с, таким образом, в дистиллированных условиях, каждый клиент должен получить примерно 15КБ/с. Как вы можете видеть, они на самом деле получают почти одно и тоже (горизонтальные линии).

 

 

Клиент 2 отключается в некоторой точке (смотрите, как красная линия пошла вниз), а Клиент 1 быстро осознаёт, что теперь он может использовать всю доступную пропускную способность. На самом деле, он сперва немного промахивается, но потом находит предел и покрывает примерно 29.5КБ/с. Это не всегда будет выглядеть так красиво, но это, честно говоря, был первый запуск, что я захватил.

 

Я знаю, о чём вы думаете прямо сейчас: "Окей, отличный график, но почему я должен беспокоиться об этом, будет ли с этим лучше играться?". На самом деле, я встревожен и взволнован перед следующим обновлением - да, сжатие и изменения в перегрузках прибудут на ПК на этой неделе. Игроки на консолях получат это чуть позднее. Сжатие легко оценить количественно и я уверяю, это будет работать как и ожидается. Контроль перегрузок же менее предсказуем, так что сложнее измерить его воздействие. Я не ожидаю того, что это будет идеально, ничто не идеально, я ожидаю, что это окажется лучше того, что у нас есть сейчас. Это не повлияет на лаги непосредственно, но улучшенный контроль перегрузок приведёт к меньшей "летальности" в этом плане. Мы не можем заставить данные передаваться быстрее (пока мы не превысили скорость света, это следующее над чем мы будем работать), но мы стараемся, чтобы этот процесс не стал медленнее.

 

- maciejs

 

Оригинал статьи:

https://forums.warframe.com/index.php?/topic/391492-network-compression-and-congestion-control/

 

Перевод: She0g0gath

Правки: ILeora

[WhiteDragon_RU_]

Очень интересное чтиво. Спасибо за перевод.

[-Well-]

К делу не относится. Оффтоп

(пока мы не превысили скорость света, это следующее над чем мы будем работать)

Боженька, миленький, прошу тебя. Прости этим заблудшим овечкам их гордыню и тщеславие. Дай им толику разума и самокритики. Одели их своей благодатью и милостью, даруй им счастье, здоровье, мудрость, только пусть больше, ****, не плодятся. Аминь.

[White_Lugaru]

 

К делу не относится. Оффтоп

 

Боженька, миленький, прошу тебя. Прости этим заблудшим овечкам их гордыню и тщеславие. Дай им толику разума и самокритики. Одели их своей благодатью и милостью, даруй им счастье, здоровье, мудрость, только пусть больше, ****, не плодятся. Аминь.

 

А с юмором то туговато..

[keensight]

А с юмором то туговато..

тааалана) эт походу как раз у тебя туговато с юмором. -Well- пошутил же ))

 

[Ikotaa]

тааалана) эт походу как раз у тебя туговато с юмором. -Well- пошутил же ))

Да что ты говоришь, правда что ли ?  Абалдеть, это оказывается шутка :D

Edited January 29, 2015 by Ikotaa

[AnimaMea]

Наконец то начали работать над улучшением сетевой составляющей в игре.

У меня проблем с натом нету, т.к. имеется статический ip, но иногда были проблемы с портами, хотя они открыты на роутере/фаерволе.

Но не суть, главное начали хоть над чем то работать.

Осталось решить проблему просадок фпс.