Реальная история, основанная на вымышленных событиях.
Все совпадения — неслучайны.
Все шутки — несмешны.

Всем привет!

На связи Никита — системный инженер из компании SЕMrush. Сегодня я расскажу вам о том, как перед нами встала задача обеспечить стабильность работы нашего сервиса semrush.com в Китае, и с какими проблемами мы столкнулись в ходе ее выполнения (учитывая местонахождение нашего дата-центра на восточном побережье США).

Это будет большая история, разбитая на несколько статей. Расскажу, как все это было у нас: от полностью неработающего сервиса из Китая, до показателей работы сервиса на уровне его американской версии для американцев. Обещаю, будет интересно и полезно. Итак, поехали.

Проблемы китайского интернета

Даже самый далекий человек от специфики сетевого администрирования хотя бы раз, да слышал о Великом Китайском Фаерволе. Ууу, звучит круто, да? Но что это такое, как оно работает на самом деле — вопрос довольно сложный. В интернете можно найти много статей, посвященных этому, но с технической точки зрения устройство этого фаервола нигде не описано. Что, впрочем, неудивительно. Признаюсь сразу, по итогам года работы я не смогу сказать точно, как он работает, но смогу рассказать о своих замечаниях и практических выводах. И начнем мы со слухов об этом фаерволе.

От переводчика:
Представляю вашему вниманию статью авторства Andy Gainey, в прошлом независимого разработчика игровых инструментов, ныне сотрудника Paradox Development Studio. На мой взгляд, автор играючи создал один из лучших процедурных генераторов планет с открытым исходным кодом.

Всем привет. Все кто хоть немного разбирался в теме OpenGL знают, что существует большое количество статей и курсов по этой теме, но многие не затрагивают современный API, а часть из них вообще рассказывают про glBegin и glEnd. Я постараюсь охватить некоторые нюансы нового API начиная с 4-й версии. Ссылка на вторую часть статьи

14 мая, когда Трамп готовился спустить всех собак на Huawei, я мирно сидел в Шеньжене на Huawei STW 2019 — большой конференции на 1000 участников — в программе которой были доклады Филипа Вонга, вице-президента по исследованиям TSMC по перспективам не-фон-неймановских вычислительных архитектур, и Хенга Ляо, Huawei Fellow, Chief Scientist Huawei 2012 Lab, на тему разработки новой архитектуры тензорных процессоров и нейропроцессоров. TSMC, если знаете, делает нейроускорители для Apple и Huawei по технологии 7 nm (которой мало кто владеет), а Huawei по нейропроцессорам готова составить серьезную конкуренцию Google и NVIDIA.

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

Только в прошлом году в тему было вложено больше 3 миллиардов долларов. Google уже давно объявил нейросети стратегическим направлением, активно строит их аппаратную и программную поддержку. NVIDIA, почувствовав, что трон зашатался, вкладывает фантастические усилия в библиотеки ускорения нейросетей и новое железо. Intel в 2016 году потратил 0,8 миллиарда на покупку двух компаний, занимающихся аппаратным ускорением нейросетей. И это при том, что основные покупки еще не начались, а количество игроков перевалило за полсотни и быстро растет.


TPU, VPU, IPU, DPU, NPU, RPU, NNP — что все это означает и кто победит? Попробуем разобраться. Кому интересно — велкам под кат!

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

А еще там разбирается характер персонажей на примере сторонников теории плоской Земли.


Сценарий фильма «Апокалипсис сегодня» (1979) по мотивам книги Джозефа Конрада «Сердце тьмы» (1899)

Вы пока не разбираетесь, почему ReLU лучше сигмоиды, чем отличается Rprop от RMSprop, зачем нормализировать сигналы и что такое skip connection? Зачем нейронной сети нужен граф, и какую он совершил ошибку, что она распространяется обратно? У вас есть проект с компьютерным зрением или, может быть, делаете межгалактического робота для борьбы с грязными тарелками, и хотите, чтобы он мог сам решать, отмывать или и так сойдет?

Мы запускаем открытый курс «Нейронные сети и компьютерное зрение», который адресован тем, кто в этой области делает первые шаги. Курс разработан экспертами Samsung Research Russia: Исследовательского центра Samsung и Центра искусственного интеллекта Samsung в Москве. Сильные стороны курса:

• авторы курса знают, о чем говорят: это инженеры московского Центра искусственного интеллекта Samsung, Михаил Романов и Игорь Слинько;
• есть как теория с задачками, так и практика на PyTorch
• приступаем к практике сразу после освоения минимальных теоретических знаний.
• лучшие студенты будут приглашены на собеседование в Samsung Research Russia!

На днях, как известно, в открытый доступ был выпущен тестовый клиент Telegram Open Network (подробнее о TON — здесь и здесь; о работе тестовой сети — здесь). Я поскорее начал его ставить; инструкция по установке, описанная в README, была на счастье простой, и это вселяло оптимизм. Но вскоре начались проблемы.

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

И знаете, все получилось. Пригодный к использованию справочник готов, можно качать и пользоваться. А еще мы сделали подсказки, которые ускоряют ввод подразделений в электронные формы.

Наверно худшее, что случилось в области процедурной генерации контента (если считать, что это действительно область процедурной генерации контента, в чём я уверен не полностью) — это шум Перлина. Шум Перлина невероятно хорошо подходит (по крайней мере, если не приглядываться слишком внимательно) для генерации интересных ландшафтов. В сабреддите /r/proceduralgeneration недели не проходит без того, чтобы кто-нибудь не опубликовал «систему процедурной генерации», которая оказывается визуализированным разными цветами шумом Перлина. (За время написания этой статьи появилось два таких поста!)


Я не хочу унизить шум Перлина. Это невероятно полезный для процедурной генерации инструмент, ставший точкой входа в эту область для множества людей, в том числе и меня. Но в то же время он очень сбивает с толку, потому что подразумевает, что процедурная генерация намного проще, чем это есть на самом деле. Большинство еженедельных постов о «системах процедурной генерации» в /r/proceduralgeneration исчезают без следа, когда их авторы обнаруживают, что следующий шаг в процедурной генерации гораздо сложнее. Истина в том, что шум Перлина стал своего рода счастливой случайностью. Он отлично подходит для генерации интересных ландшафтов, но на то нет систематических или повторяемых причин.

По работе приходится участвовать в разных проектах, поэтому я хорошо знаю, как работают все мои коллеги. Помню, что компания начала использовать Git буквально за пару недель до моего прихода. На мониторах разработчиков кругом висели наклейки с напоминанием: сначала add, потом коммит, затем пуш.


Они не знали, зачем. Программистам просто сказали строго следовать инструкции, иначе беда. Но проблемы возникали так часто, что я решила провести семинар по Git.

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

Введение

Алгоритм был написан как часть работы на получение степени бакалавра и основан на статье Ma et al (2014). Целью работы было ускорение алгоритма и дополнение его новыми функциями. Я вполне доволен результатом, потому что мы сделали алгоритм достаточно быстрым, чтобы использовать его во время выполнения игры. После завершения бакалаврской работы мы решили превратить её в статью и отправить на конференцию Game-ON 2018.

Алгоритм

Для создания уровня игры алгоритм получает в качестве входных данных набор полигональных строительных блоков и граф связности уровня (топологию уровня). Узлы графа обозначают комнаты, а рёбра определяют связи между ними. Цель алгоритма — назначить каждому узлу графа форму и расположение комнаты таким образом, чтобы никакие две формы комнат не пересекались, и каждая пара соседних комнат могла соединяться дверьми.

Незадолго до празднования самого жуткого дня в году команда из Массачусетского технологического института запустила «Машину кошмаров». Вдохновившись классическими «ужастиками» и возможностями искусственного интеллекта, Пинар Янардаг, Мануэль Кебриан и Ияд Равхан научили нейронную сеть создавать из популярных достопримечательностей мрачные городские пейзажи, а из лиц знаменитостей — пугающие портреты.

От переводчика: У меня возникла необходимость разобраться с работой UDP-сокетов в неблокирующем режиме в java и создать свой собственный класс для работы с сетевыми соединениями на их основе. К сожалению, толковой русскоязычной документации на эту тему я не нашёл. Зато наткнулся на несколько попыток на хабре осветить тему создания надёжного соединения поверх UDP. В том числе и перевод нескольких статей Гленна Фидлера, сделанный пользователем bvasilyev. И хотя статьи рассматривают создание подобного подключения для применения его в играх (не совсем то, что мне необходимо), а также языком реализации является не java, а c++, они стали для меня отправной точкой. К сожалению bvasilyev около года назад прервал перевод данного цикла, а самое интересное осталось на языке оригинала. Поэтому я решил перевести четвёртую статью цикла и переписать реализацию виртуального соединения из третей статьи цикла на java (чуть позже выложу). Ну а для того, чтоб данной статьёй мог воспользоваться кто-либо, кроме меня, выкладываю её здесь. Профессиональным переводом, к сожалению, никогда не занимался, всегда изучал англоязычную документацию. Но в данном случае, из-за многочисленного употребления некоторых слов в совершенно различных значениях, а также в роли наименования всевозможных определений, неоднократно — в пределах одного предложения, счёл более целесообразным осуществить перевод, а после уже работать с текстом на привычном для себя языке. Поправки и аргументированные предложения приветствуются.

Первая статья
Вторая статья
Третья статья

(напомню: переведены bvasilyev)

---

Надежность, упорядочивание и избежание перегрузок поверх UDP

Вступление

Привет, меня зовут Гленн Фидлер и я приветствую вас в своей четвёртой статье из цикла “Сетевое программирование для разработчиков игр”.

В предыдущей статье, мы создали свою собственную концепцию виртуального соединения на основе UDP.

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

Это, безусловно, самая сложная часть низкоуровневой сетевой работы в играх, так что эта статья будет весьма насыщенной, поэтому пристегнулись и поехали!

Проблемы с TCP

Те из вас, кто знаком с TCP, знают, что он уже имеет свою внутреннюю концепцию соединений, с надёжной и упорядоченной системой передачи пакетов и предотвращением перегрузок, так зачем же мы пишем свою собственную мини версию TCP на основе UDP?

От переводчика: Это перевод третьей статьи из цикла «Networking for game programmers». Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.
Первая статья — http://habrahabr.ru/post/209144/
Вторая статья — http://habrahabr.ru/post/209524/

---

Виртуальные соединения поверх UDP

Введение

Привет. Меня зовут Гленн Фидлер и я приветствую вас в третьей статье из цикла “Сетевое программирование для разработчиков игр”.

В предыдущей статье мы разобрались, как отправлять и принимать пакеты, используя протокол UDP.

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


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

Но сначала, нам нужно более плотно разобраться, как работает интернет.

От переводчика: Это перевод второй статьи из цикла «Networking for game programmers». Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.
Первая статья — http://habrahabr.ru/post/209144/

---

Прием и передача пакетов данных

Введение

Привет, меня зовут Гленн Фидлер и я приветствую вас в своей второй статье из цикла “Сетевое программирование для разработчиков игр”.


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

А сейчас я собираюсь рассказать вам, как на практике использовать UDP для отправки и приема пакетов.

BSD сокеты

В большинстве современных ОС имеется какая-нибудь реализация сокетов, основанная на BSD сокетах (сокетах Беркли).

Сокеты BSD оперируют простыми функциями, такими, как “socket”, “bind”, “sendto” и “recvfrom”. Конечно, вы можете обращаться к этим функциями напрямую, но в таком случае ваш код будет зависим от платформы, так как их реализации в разных ОС могут немного отличаться.

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

От переводчика: Это перевод первой статьи из цикла «Networking for game programmers». Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.

---

Привет, меня зовут Гленн Фидлер и я приветствую вас в первой статье из моей онлайн-книги “Сетевое программирование для разрабочиков игр”.


В этой статье мы начнем с самых базовых аспектов сетевого программирования — приема и передачи данных по сети. Прием и передача данных — это основная и наиболее простая часть из всего круга задач, которыми занимаются сетевые программисты, но часто бывает сложно определить, каким путем лучше двигаться. Уделите этой части достаточно внимания — если у вас останется непонимание, то это может привести к ужасным последствиям для вашей многопользовательской игры в дальнейшем!

Вы, скорее всего, уже что-нибудь слышали о сокетах, и, возможно, знаете, что они делятся на два основных типа — TCP и UDP. Первое, что нужно решить при разработке многопользовательской игры — это какой тип сокетов использовать — TCP, UDP, или оба?

Примечание переводчика: этой статье уже 17 лет, и интересна она только с исторической точки зрения. Любопытно узнать, как удавалось разработчикам добиться плавной сетевой игры в эпоху 28,8k-модемов и первых «Пентиумов».

В этой статье рассказывается об архитектуре и реализации, а также о некоторых уроках, полученных при создании многопользовательского (сетевого) кода игр Age of Empires 1 и 2. Также в ней излагаются современные и будущие подходы с созданию сетевой архитектуры, используемые Ensemble Studios в своих игровых движках.

Мультиплеер Age of Empires: требования к структуре

В начале работы над многопользовательским кодом Age of Empires в 1996 году мы поставили перед собой очень конкретные цели, необходимые для реализации требуемого игрового процесса.

Чем больше узнаёшь в своей области знания, тем чётче понимаешь, что никто не может знать всего.

По какой-то причине (за что, господи, за что?) моей областью стала разработка игр. Каждый, кто работает в этой сфере, скажет вам: никогда не добавляй сетевой многопользовательский режим в уже готовую игру, никогда, пьяный ты клоун.

Как бы то ни было, я именно это и сделал, и ненавижу себя за это. На удивление, вышло замечательно. Никто из нас не знает всего.

Проблема №1: ресурсы

Первый вопрос, который у меня возник: как сказать клиенту, что для рендеринга объекта нужно использовать такой-то меш?

Сериализировать весь меш? Не стоит, у клиента он уже есть на диске.

Передавать имя файла? Не-а, малоэффективно и небезопасно.

Ну ладно, может быть, просто строковый идентификатор?

К счастью, прежде чем у меня появилось время на реализацию собственных бредовых идей, я посмотрел доклад Майка Эктона, в котором он говорил об опасностях «ленивого принятия решений». Смысл в следующем: строки позволяют разработчикам лениво игнорировать принятие решений до момента создания работающего приложения, когда исправлять ошибки уже поздно.

Проблема многопользовательских игр

Одна из самых сложных задач многопользовательских игр заключается в синхронизации состояний всех игроков с состоянием сервера. В Интернете есть хорошие статьи по этой теме. Однако в них не достаёт кое-каких подробностей, что может сбивать с толку новичков в программировании игр. Надеюсь, что у меня получится объяснить всё в этой статье.

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

Обычно программа игры должна симулировать следующее:

изменения в окружении с учётом времени и вводимых игроками данных.

Игра — это программа, хранящая состояние, поэтому она зависит от времени (реального или логического). Например, PACMAN симулирует окружение, в котором постоянно перемещаются призраки.

Многопользовательская игра не является исключением, однако из-за взаимодействия игроков её сложность намного выше.