Как бы выглядела интернет-система в игре EvE Online

Автор оригинала: Ben Cox
  • Перевод
EvE online — увлекательная игра. Это одна из немногих ММО, в которых есть только один «сервер» для входа, что означает, что все играют в одном и том же логическом мире. У нее также был захватывающий набор событий, которые произошли внутри игры, и также она остается очень визуально привлекательной игрой:


Здесь также находится обширная карта мира, на которой могут разместиться все эти игроки. На своем пике у EvE было 63 000 игроков онлайн в одном мире с 500 000 оформленных платных подписок на пике популярности, и, хотя с каждым годом это число становится все меньше, мир остается невероятно большим. Это означает, что переход из одной стороны к другой — это значительное количество времени (а также риск из-за зависимости игрока от фракции).

Перевод выполнен при поддержке компании EDISON Software, которая профессионально занимается безопасностью, а так же разрабатывает системы электронной медицинской проверки.

Вы путешествуете по разным областям, используя варп-режим(в пределах одной и той же системы), или прыгаете в разные системы с помощью прыжковых врат:

image

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

image

Я всегда рассматривал эту карту как сеть, это большая сеть систем, которые соединяются друг с другом, чтобы люди могли проходить через них, и большинство систем имеют более двух прыжковых врат. Это заставило меня задуматься о том, что произойдет, если вы в буквальном смысле взяли идею карты как сети? Как будет выглядеть интернет-система EvE?

Для этого нам нужно понять, как работает настоящий интернет. Интернет — это большая коллекция интернет-провайдеров, которые все численно идентифицируются с помощью стандартизированного и уникального номера интернет-провайдера, называемого номером автономной системы или ASN (или AS для более короткий вариант). Этим AS требуется способ обмена маршрутами друг с другом, так как им будут принадлежать диапазоны IP-адресов, и им нужен способ сообщить другим интернет-провайдерам, что их маршрутизаторы могут маршрутизировать эти IP-адреса. Для этого мир остановился на протоколе граничного шлюза или BGP.

BGP работает, «сообщая» другим AS (известным как узел) их маршруты:

image

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

image

Однако это поведение полезно только в том случае, если вы используете BGP для отправки маршрутов во внутренние маршрутизаторы, поскольку современный Интернет имеет различные логические отношения друг с другом. Вместо сети современный интернет выглядит примерно так:

image

Тем не менее, EvE online установлен в будущем. Кто знает, полагается ли интернет на эту схему маршрутизации для получения прибыли. Давайте представим, что это не так, чтобы мы могли видеть, как BGP масштабируется в более крупных сетях.

Для этого нам нужно смоделировать реальное поведение BGP-роутера и соединения. Учитывая, что EvE имеет относительно низкое 8000~ количество систем, и реззоные 13,8 тыс. связей между ними. Я предположил, что на самом деле будет невозможно запустить 8000~ виртуальных машин с реальным BGP и сетью, чтобы выяснить, как эти реальные системы выглядят, когда действуют вместе как сеть.

image

Тем не менее, у нас нет неограниченных ресурсов, поэтому нам нужно будет найти способ сделать наименьший образ Linux как при использовании дискового пространства, так и при использовании памяти. Для этого я обратил внимание на встраиваемые системы, поскольку встраиваемые системы часто должны работать в средах с очень низким уровнем ресурсов. Я наткнулся на Buildroot, и через несколько часов у меня был небольшой образ Linux, содержащий только то, что мне нужно для работы этого проекта.

$ ls -alh
total 17M
drwxrwxr-x 2 ben ben 4.0K Jan 22 22:46 .
drwxrwxr-x 6 ben ben 4.0K Jan 22 22:45 ..
-rw-r--r-- 1 ben ben 7.0M Jan 22 22:46 bzImage
-rw-r--r-- 1 ben ben  10M Jan 22 22:46 rootfs.ext2

Этот образ содержит загрузочную linux, которая также имеет: * Bird 2 BGP Daemon * tcpdump и My Traceroute (mtr) для сетевой отладки * busybox для базовой оболочки и системных утилит

Этот образ можно легко запустить в qemu с небольшим количеством опций:

qemu-system-i386 -kernel ../bzImage \
  -hda  rootfs.ext2 \
  -hdb fat:./30045343/ \
  -append "root=/dev/sda rw" \
  -m 64

Для работы в сети я решил использовать недокументированную функцию из qemu (в моей версии), в которой вы можете направить два процесса qemu друг на друга и использовать сокеты UDP для передачи данных между ними. Это удобно, так как мы планируем предоставить большое количество ссылок, поэтому использование обычного метода адаптеров TUN/TAP может быстро привести к беспорядку.

Поскольку эта функция отчасти недокументирована, возникли некоторые проблемы с ее работой. Мне потребовалось много времени, чтобы понять, что сетевое имя в командной строке должно быть одинаковым для обеих сторон соединения. Позже выяснилось что эта функция уже хорошо документирована, как это обычно бывает. Изменениям нужно время чтобы добраться в более старые версии дистрибутива.

Как только это сработало, у нас появилось пара виртуальных машин, которые могут отправлять пакеты между собой, а гипервизор передает их как UDP-дейтаграммы. Поскольку мы будем запускать большое количество таких систем, нам потребуется быстрый способ их настройки с использованием предварительно созданной конфигурации. Для этого мы можем использовать удобную функцию qemu, которая позволяет вам взять каталог на гипервизоре и превратить его в виртуальную файловую систему FAT32. Это полезно, поскольку позволяет нам создавать каталог для каждой системы, которую мы планируем запустить, и каждый процесс qemu указывает на этот каталог, что означает, что мы можем использовать один и тот же загрузочный образ для всех виртуальных машин в кластере.

Поскольку каждая система имеет 64 МБ ОЗУ, и мы планируем использовать 8000 ~ ВМ, нам, безусловно, потребуется приличный объем ОЗУ. Для этого я использовал 3 m2.xlarge.x86 с packet.net’s, поскольку они предлагают 256 ГБ оперативной памяти с 2x Xeon Gold 5120, что означает, что они имеют приличное количество поддержки.

image

Я использовал другой проект с открытым исходным кодом для создания карты EvE в форме JSON, а затем создал программу собственной конфигурации на основе этих данных. Проведя несколько тестовых прогонов всего нескольких систем, я доказал, что они могут брать конфигурацию из VFAT и устанавливать сеансы BGP друг с другом по этому поводу.

image

Итак, я сделал решающий шаг к загрузке вселенной:

image

Сначала я попытался запустить все системы в одном большом событии, но, к сожалению, это привело к большому взрыву в отношении загрузки системы, поэтому после этого я переключился на запуск системы каждые 2,5 секунды и 48 ядер системы в итоге позаботились об этом.

image

Во время процесса загрузки я обнаружил, что вы увидите большие «взрывы» использования ЦП над всеми виртуальными машинами, позже я выяснил, что это были большие части вселенной, соединяющиеся друг с другом, таким образом вызывая большие объемы трафика BGP по обе стороны недавно подключенных виртуальных машин.

image

root@evehyper1:~/147.75.81.189# ifstat -i bond0,lo
      bond0                 lo        
 KB/s in  KB/s out   KB/s in  KB/s out
  690.46    157.37  11568.95  11568.95
  352.62    392.74  20413.64  20413.64
  468.95    424.58  21983.50  21983.50

В итоге мы увидели несколько довольно удивительных путей BGP, поскольку каждая система объявляет /48 адресов IPv6, вы можете видеть маршруты к каждой системе и ко всем другим системам, через которые он должен был бы пройти, чтобы попасть туда.

$ birdc6 s ro all

2a07:1500:b4f::/48   unicast [session0 18:13:15.471] * (100) [AS2895i]
        via 2a07:1500:d45::2215 on eth0
        Type: BGP univ
        BGP.origin: IGP
        BGP.as_path: 3397 3396 3394 3385 3386 3387 2049 2051 2721 2720
        2719 2692 2645 2644 2643 145 144 146 2755 1381 1385 1386 1446 
        1448 849 847 862 867 863 854 861 859 1262 1263 1264 1266 1267 
        2890 2892 2895
        BGP.next_hop: 2a07:1500:d45::2215 fe80::5054:ff:fe6e:5068
        BGP.local_pref: 100

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

image

После этого я подумал, что еще вы можете отобразить в маршрутизируемых сетях BGP? Не могли бы вы использовать модель меньшего размера, чтобы проверить, как работает конфигурация маршрутизации в крупных сетях? Я подготовил файл, который отобразил лондонскую систему метро, чтобы проверить это:

image

Система TFL намного меньше и имеет намного больше прыжков, которые имеют только одно направление, поскольку большинство станций имеют только одну «линию» транспорта, однако мы можем извлечь из этого одну вещь, мы можем использовать это, чтобы безопасно играть с BGP MED’s.

Однако существует проблема, когда мы рассматриваем карту TFL как сеть BGP, в реальном мире время/задержка между каждой остановкой не одинаковы, и поэтому, если бы мы имитировали эту задержку, мы бы не шли в обход системы так быстро, как мы могли бы, так как мы смотрим только на наименьшее количество станций, чтобы пройти путь.

image

Однако благодаря Закону о свободе информации (FOIA), запрос, который был отправлен в TFL, предоставил нам время, необходимое для перехода с одной станции на другую. Они были сгенерированы в конфигурации BGP маршрутизаторов, например:

protocol bgp session1 {
    neighbor 2a07:1500:34::62 as 1337;
    source address 2a07:1500:34::63;
    local as 1337;
    
    enable extended messages;
    enable route refresh;

    ipv6 {
        import filter{
            bgp_med = bgp_med + 162;
            accept;
        };
        export all;
    };
}


protocol bgp session2 {
    neighbor 2a07:1500:1a::b3 as 1337;
    source address 2a07:1500:1a::b2;
    local as 1337;
    
    enable extended messages;
    enable route refresh;

    ipv6 {
        import filter{
            bgp_med = bgp_med + 486;
            accept;
        };
        export all;
    };
}

В session1 временной промежуток между двумя станциями составляет 1,6 минуты, другой путь из этой станции — 4,86 минуты. Этот номер добавляется в маршрут для каждой станции/маршрутизатора, через которую он проходит. Это означает, что каждый маршрутизатор/станция в сети знает, что пришло время добраться до каждой станции через каждый маршрут:

image

Это означает, что traceroutes точно определяет, как вы можете перемещаться по Лондону, например, на мою станцию в Паддингтон:

image

Мы также можем повеселиться с BGP, имитируя техническое обслуживание или инцидент на станции Ватерлоо:

image

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

image

И это магия BGP MED в маршрутизации!

Код для всего этого уже доступен. Вы можете создавать свои собственные сетевые структуры с достаточно простой JSON-схемой или просто использовать EvE онлайн или TFL, поскольку они уже находятся в репозитории.

Вы можете найти весь код для этого здесь
Edison
99,00
Изобретаем успех: софт и стартапы
Поддержать автора
Поделиться публикацией

Комментарии 31

    0
    Есть нюанс: прыжковые врата и варп движки не могут передавать интернет, в моем понимании для этого придется телепортировать туда-сюда условную «флешку». И чем больше данных передаем тем больше размер флешки… А к ней еще надо крутить способ соединения с сетью системы, потом приходим к транзакциям…
    ЗЫ Возможно, я не нашел в тексте упоминание способа передачи между системами, но я честно искал.
      0
      Почему бы вратам не иметь способ связи друг с другом? Можно предположить, что для обработки прыжка нужна коммуникация между передающими и принимающими вратами, так что и поток данных должен быть.
        0
        Ели связь возможна без варп прыжков — нет смысла в топологии основанной на прыжковых вратах.
        ЗЫ Хотя, подумалось, если условный прокол пространства и соединение 2х точек требует очень большой энергии и дает возможность прокинуть через этот канал связь — есть вероятность, что выделение таких же мощностей для связи не целесообразно. Но как то это очень напоминает сову на глобусе.
          0
          Как раз так и есть. Почему сразу сова?
          Если бы «прокол пространства» не требововал бы уймы энергии и использования очень тяжелого и мощного оборудования, то эти самые «врата» были бы просто не нужны в принципе. Все нужное оборудование ставили бы непосредственно на космические корабли и они прыгали бы между звездными системами без использования врат.

          Как например во вселенной «звездных войн», где все более-менее приличные КК (кроме совсем уж легких и простых) имеют прыжковый гипердвигатель на борту.
            0
            Сова, потому, что варп технология не подразумевает прокола пространства с устойчивым соединением двух точек. по крайней мере в классическом понимании. Это перемещение со скоростью превышающей свет путем «перекачки» темной материи с носа корабля за него… Окей, остановимся на том, что это врата прокола пространства в каких то аномалиях и поэтому не получилось это пространство проколоть «по уму» и нагородили такую запутанную хрень.
          +1
          Если именно бэкстори и канон EVE почитать — все там есть, и связь врат между собой и 'просто' сверхсветовая связь.
          А кроме врат — есть еще такая штука как jump bridge (по сути 'свои' врата — доступ ограничен, расходуют ресурсы) и корабли с прыжковыми двигателями (которые прыгают на станционарные или мобильные маяки, при этом еще и дальность зависит от типа корабля и навыков пилота), причем многие из этих кораблей — могут и обычными вратами пользоваться. Да, бонусом — не все корабли могут во все системы входить.
          В результате для решения задачи «как нам привезти из джиты в CJ-6MT немного товара» у нас есть куча вариантов: если надо реально немного — то гнать обычный транспортник прыжковыми вратами туда и обратно(но в интервале от Коноры до CJ-6MT — возможно проще будет использовать jump bridges если они есть там есть и у нас есть доступ, потом что пираты), если груз большой — возможно придется на джамп-фрейтере лететь, и маршрут в этом случае будет несимметричным, придется искать ближайшую к джите точку где можно врубить маяк (в самой джите — нельзя) и по цепочке маяков прыгать туда а из джиты — прямо на маяк уходить).

          Для боевых флотов все еще больше усложняется — потому что разные скиллы пилотов (обычно просто требования заданы заранее), потому что боевой флот может нести как способные на самостоятельный прыжок корабли так и не способные, потому что есть такая штука как портал титана (мобильный jump bridge по сути), потому что надо учитывать а в чью систему мы запрыгиваем…

          Ну и есть специальные калькуляторы маршрутов — evemaps.dotlan.net/jump и www.eve-icsc.com/jumptools/jumpplanner.php например.

          С Wormhole'ами все становится еще интереснее — то что там вместо врат — вообще существует не долго (зависит от времени и прошедшей массы)) и карта связей тоже динамическая.
          +2
          Есть же ансибль. А вообще у Вернора Винджа (например Пламя над бездной) описана довольно интересная концепция, когда бок о бок существуют мгновенная передача информации через ансибли и обычный интернет через радиосеть.
          0
          В Еве и так компьютеры соединены в сеть. Мгновенная связь на любые расстояния.
            0
            В таком случае не понятна заморочка с топологией сети, основанной на карте. Если связь мгновенна и на любое расстояние — плодить системы с узким горлом в связующих системах кажется сомнительной идеей.
              0
              Это зависит от того, что собой представляет устройство мгновенной связи. Если это, к примеру, куб размером 1x1x1 м, который весит одну тонну и требует ИП мощностью 10 кВт для работы, то как бы более практично поставить по одному кубу на много систем с обычной связью, и вот нам снова нужны таблицы маршрутизации. Поскольку вряд-ли одно устройство имеет неограниченную полосу пропускания, и нам ещё нужно резервирование — вот и появляется несколько кубов в одной системе, со всеми вытекающими.
            +4
            Нет-нет-нет! Вы не заставите меня в очередной раз установить Еву!
              +3
              Зачем эта личная жизнь? В Еве хорошо, в Еве альянс ждет, в Еве еще столько дел не переделано, SP встали, надо снова очередь забить.
              +5
              и также она остается очень визуально привлекательной игрой

              и именно поэтому её второе имя «эксель в космосе»
                +2
                Фон у этого экселя красивый.
                  +1
                  Таблицы онлайн.
                    0
                    Список объектов в космосе теперь называется экселем? Никогда не понимал этих нападок на таблицы. Предложите более юзабельный способ взаимодействия с сотнями объектов.
                      +1
                      Никаких нападок, просто называть еву очень визуально привлекательной игрой по меньшей мере странно (если только ничего принципиально не изменилось за 6 лет моего отсутствия), учитывая что спустя пару месяцев игры ты учишься летать по приборам и больше ничего, кроме таблиц, на твоём экране нет. Отсюда собственно и аналогия с экселем. А так да, вывод информации таблицами наиболее подходящий вариант для такой игры.
                    +1

                    "Это одна из немногих ММО, в которых есть только один «сервер» для входа"
                    Вообще-то 2 сервера: международный и китайский. +1 постоянный тестовый. + Еще пара резервных тестовых.

                      +1
                      Вообще-то 2 сервера: международный и китайский.

                      Т.е. разработчики — реалисты и, поэтому, так, на всякий случай, выделили китайцам отдельный вход?
                        0
                        китайский же закрыли.
                        сейчас китайцы «плавно» вливаются на общий.
                        да год уже вливаются, если не больше.
                          0
                          Кто тебе такую чушь сказал?

                          Китайский как работал, так и работает.

                          tvr, это из-за политики Китая.
                      –1
                      Вспомнил по этой игре забавный факт: Роскомнадзор внес в реестр запрещенных форум этой игры по решению Госнаркоконтроля еще в далеком 2012 году за… пропаганду наркотиков (т.к. пользователи использовали слово «наркотик» в качестве термина прокачки персонажей).
                        0
                        блин.
                        фсё.
                        = продам всех персов =
                        ева для меня теперь не идеальная игра.
                        :)
                          0
                          Мне вот интересно, что у них там за «единственный сервак», что на нем все это крутится и не лагает???
                            +1
                            Ну почему не лагает. Когда сильно сложно — то просто понижают течение игрового времени, насколько я знаю, т.е. игровая секунда обсчитывается в реальных 10.
                              0
                              Текущая итерация кластера
                              Каждая система занимает один поток процессора, большинство систем делят сервера, загруженным — выделяют отдельные.
                                0
                                Единый игровой мир (типа сервер). А железных серверов, обеспечивающих этот мир довольно много.
                                Самые интересное, когда планируется большая битва — пишешь заявку — типа в такой-то звездной системе и паре соседних планируем очередной эпик батл на пяток тысяч человек, просим обеспечить системы доп. мощностями. Лагает конечно и замедление времени включается по полной, но меньше, чем без выделения доп. ресурсов.
                                  0
                                  Там кластер хитрый. CCP не раз описывали что там и какие апгрейды были.

                                  А насчет 'не лагает'… там изначально была проблема — архитектура требует максимуум один сервер на звездную систему. с одним процессом. с игровой логикой на Stackless Python. При этом на этом сервере еще и другие задачи. При этом перевод звездной системы на другой физический сервер — требует ее гашения. Если при прыжке через врата сообщение про то что врата оффлайн — ну значит система куда прыгаем не запустилась еще или уже лежит.

                                  А теперь вспомним что ситуация когда в сфере в 200 км запросто могут появится и тысячи кораблей которые воздействуют друг на друга (+ракеты + дроны)… вот после этого — и появляются внутриигровые новости про вспышки на Солнце и разговоры что кто-то опять достал лагогенератор (потому что все это веселье на разных игроков — влияет по разному).

                                  Потихоньку исправляли все — и выкидывали все что не нужно (чат, персонажей, торговлю) на отдельные серверы и Stackless Python активно тюнили и придумали такую штуку как Time Dilation(если сервер видит что не справляется — ну значит тормозится игровое время, пусть слайды но у всех одинаково и хоть как то можно жить) и возможность игрокам (не всем) скинуть заявку вида 'есть мнение что вот в этой системе скоро будет МНОГО кораблей хотя пока- ни одного, вы там ее перекиньте на сервер покруче' и Главную Базу Данных вообще на железке от RAMSAN хранят (RAM-диск в несколько терабайт).
                                  0
                                  <<Нет-нет-нет! Вы не заставите меня в очередной раз установить Еву!>>
                                  пока акк стоил немножко денех- был годный эвент, моему акку 5 лет…
                                    +1
                                    image

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое