Продължаваме да ви разказваме как беше организирано нашето лазерно търсене с унищожаването на сървъра. Започнете в предишния .
Общо бекендът на играта имаше 6 архитектурни единици, които ще анализираме в тази статия:
- Бекенд на игрови обекти, които отговаряха за игровите механизми
- Шина за обмен на данни от бекенд и сайт на VPS
- Преводач от бекенд заявки (елементи на играта) към Arduino и хардуер на място
- Arduino, който отговаряше за управлението на релетата, получаваше команди от преводача и вършеше същинската работа
- Реални устройства: вентилатор, гирлянди, подови лампи и др.
- Frontend - самият уебсайт на Falcon, от който играчите управляват устройства
Нека да преминем през всеки от тях.
Бекенд на игрови обекти
Бекендът беше реализиран като приложение за пролетно стартиране: имаше няколко контролера за почивка, крайна точка на уебсокет и услуги с логика на играта.
Имаше само три контролера:
- Мегатрон. Текущата страница на Megatron беше изпратена чрез GET заявки: преди и след включване на захранването. Лазерът се задейства през POST заявката.
- Картографиране на страници с тилда, така че да се обслужват по име на страница. Tilde създава страници за експортиране не с оригинални имена, а с вътрешен идентификатор и информация за съответствие.
- Captcha контролер за обслужване на сървърна captcha с псевдо-високо натоварване.
Крайната точка на Websocket беше използвана за управление на джаджи: лампи, гирлянди и букви. Беше избрано да показва синхронно на всички играчи текущото състояние на устройството: дали е включено или изключено, активно или не, какъв цвят на буквата свети в момента на стената. За да направим задачата за включване на лазера малко по-трудна, добавихме авторизация към гирлянда и лазера с едно и също име и парола admin/admin.
Играчите можеха да го тестват, като включат гирлянда и повторят същото с лазера.
Избрахме такава тривиална двойка вход-парола, за да не измъчваме играчите с ненужен избор.
За да направи задачата малко по-интересна, идентификаторите на обекти от mongodb бяха използвани като идентификатори на устройства в стаята.
ObjectId съдържа клеймо за време: две произволни стойности, едната от които се взема въз основа на идентификатора на устройството, а втората въз основа на pid на процеса, който го генерира, и стойността на брояча. Исках да направя идентификаторите, генерирани на редовни интервали и с различни pid процеси, но с общ брояч, така че изборът на идентификатор на лазерно устройство да бъде по-интересен. В крайна сметка обаче всички започнаха с идентификатори, които се различаваха само по стойността на брояча. Това може да е направило стъпката твърде проста и не изискваща анализ на структурата на objectId.
Преводач от задните заявки
, който работи върху таймери и ги превежда от абстракции на игри във физически модел. Например „включете подовата лампа“ → „включете реле N2“.
Скриптът се свърза с опашката RabbitMQ и прехвърли заявките от опашката към Arduino. Той също така реализира логиката на паралелно превключване на светлината: заедно с някои устройства светлината върху тях беше включена, например, когато първоначално беше подадено захранване към Megatron, той беше осветен със сценична светлина. Дизайнът на осветлението за кинематографията на цялата сцена е отделна история за страхотната работа на нашия копродуцент на проекта и дизайнер на продукцията Иля Серов, за която ще разкажем в отделна публикация.
Преводачът беше отговорен и за логиката на стартиране на шредера с помощта на таймер и предаване на изображението към телевизора: таймерът за стартиране на шредера, крещеща капибара, реклама в края на играта.
Как е структурирана логиката за генериране на жетона Megatron
Пробен изстрел
На всеки 25 секунди се генерира нов жетон и може да се използва за включване на лазера за 10 секунди при мощност 10/255. Връзка към .
След това лазерът се охлади за 1 минута - през това време той беше недостъпен и не приемаше нови заявки за снимки.
Тази сила не беше достатъчна, за да прогори въжето, но всеки играч можеше да стреля по Мегатрон и да види лазерния лъч в действие.
Алгоритъмът за хеширане MD5 беше използван за генериране на токена. И схемата се получи MD5 от MD5 + брояч + секрет за боен жетон и без секрет за тестов жетон.
MD5 е препратка към комерсиален проект, който направи Павел, нашият бекендър. Само преди няколко години този проект използваше MD5 и когато той каза на архитекта на проекта, че това е остарял алгоритъм за криптиране, те започнаха да използват MD5 от MD5. Тъй като решихме да направим възможно най-нубския проект, той си спомни всичко и реши да направи малка справка.
Боен изстрел
Бойният режим на Megatron е 100% лазерна мощност при 3 вата. Това е достатъчно за 2 минути, за да изгори въжето, което държеше тежестта, да счупи аквариума и да наводни сървъра с вода.
Оставихме няколко съвета за Github на проекта: а именно кодът за генериране на токени, от който може да се разбере, че тестовите и бойните токени се генерират въз основа на един и същ индикатор за брояч. В случай на боен жетон, в допълнение към контра стойността, се използва и сол, която е почти напълно оставена в историята на промяната на тази същност, с изключение на последните два знака.
Познавайки тези данни, беше възможно да сортирате последните 2 символа на солта и всъщност да разберете, че за нея са използвани числата от Lost, преобразувани в шестнадесетичната система.
След това играчите трябваше да уловят стойността на брояча (чрез анализиране на тестовия жетон) и да генерират боен жетон, използвайки следващата стойност на брояча и солта, избрана в предишната стъпка.
Броячът просто се увеличава с всеки тестов изстрел и на всеки 25 секунди. Не сме писали за това никъде, трябваше да е малка изненада в играта.
Услуга за взаимодействие с Captcha
В света на игрите това беше същата captcha, която трябваше да се зареди, за да се включи вентилаторът и да се отвори флипчарта с подсказка. До камерата имаше лаптоп с наблюдение на натоварването.
Изчислих какво да показвам в мониторинга като текущо натоварване: температура и вентилатор на процесора. Метриките бяха прехвърлени към базата данни на времевата база и начертани от grafana.
Ако през последните 5 секунди имаше повече от 50 заявки за показване на captcha, тогава натоварването се увеличи с фиксиран + произволен брой стъпки. Изчислението беше, че 100% натоварване може да се постигне за две минути.
Всъщност в услугата имаше повече логика, отколкото беше показано във финалната игра: поставихме монитора по такъв начин, че да се вижда само въртенето на вентилатора на процесора.
В началото на търсенето те искаха да оставят Grafan достъпен от уебсайта на Falcon. Но също така съдържаше показатели за springboot от отчета на бекенд приложението, които нямахме време да изчистим, така че решихме да блокираме достъпа до него. И с право – още в началото на куеста някои играчи се досетиха, че приложението е написано в springboot framework и дори изровиха имената на някои услуги.
Хостинг и шина за данни
Инструмент за прехвърляне на информация от бекенда към сайта, VPS сървъра, на който работи RabbitMQ.
Бекендът и шината за данни бяха включени . Мощността му беше сравнима с компютъра, който виждате на екрана: 2-ядрен VPS с два гигабайта RAM. Тарифата беше таксувана за ресурси, тъй като пиковото натоварване беше планирано само за няколко дни - това правят нашите клиенти, които планират да заредят VPS за кратък период от време. След това се оказа, че натоварването е по-голямо, отколкото очаквахме, и фиксирана тарифа би била по-изгодна. Ако правите мисия, изберете линейните тарифи .
За да защитим сървъра от DDoSa, използвахме Cloudflare.
Струва си да се каже, че VPS издържа всичко с чест.
Arduino, който отговаряше за управлението на релетата, получаваше команди от преводача и вършеше същинската работа
Това е по-скоро темата на следващата статия за хардуерната част на проекта: бекендът просто изпрати заявки за включване на конкретно реле. Случи се така, че бекендът познаваше почти всички обекти и заявките от него изглеждаха като „включете този обект“. Направихме това за ранно тестване на сайта (все още не бяхме сглобили всички Arduino и релета), в крайна сметка оставихме всичко така.
Frontend
Бързо създадохме сайта на tilde, отне един работен ден и ни спести 30 хиляди от нашия бюджет.
Първоначално мислехме просто да експортираме сайта и да добавим логиката, която ни липсваше, но се натъкнахме на условия за използване, които ни забраняваха да правим това.
Не бяхме готови да нарушим лиценза, така че имаше две възможности: да внедрим всичко сами или да се свържем директно с Tilda, да говорим за проекта и да поискаме разрешение за промяна на кода.
Избрахме втория вариант и те не само ни посрещнаха, но дори ни дадоха една година безплатен бизнес акаунт, за което сме им много благодарни. Беше много неудобно да им показвам дизайна на сайта на Сокол.
В резултат на това прикрепихме js логика към интерфейса за изпращане на заявки до елементарни устройства и леко променихме стиловете на бутоните за включване и изключване на елементите на играта.
Дизайн на уебсайтове
Историята на търсенията, която си заслужава отделна глава.
Искахме да създадем не просто старомоден сайт, а абсолютно отвратителен, който нарушава всички основни правила на дизайна. В същото време беше важно да се запази достоверността: не трябваше да се нарушава историята на УНГ, да се демонстрира претенциозността на автора и играчите трябваше да вярват, че такъв сайт може да съществува и дори да доведе клиенти. И той го донесе! Докато играта вървеше, два пъти се свързахме с нас за създаване на уебсайтове.
Първоначално направих дизайна сам, опитвайки се да включа повече гифчета и блестящи елементи. Но моят дизайнерски съпруг от 10 години погледна през рамо и го отхвърли като „твърде добър“. За да нарушите правилата на дизайна, трябва да ги знаете.
Има няколко цветови комбинации, които предизвикват трайно чувство на отвращение: зелено и червено с еднаква наситеност, сиво и розово, синьо плюс кафяво. В крайна сметка се спряхме на комбинация от червено и зелено като основни цветове, добавихме гифчета с котка и избрахме 3-4 снимки на самия Соколов от стокова снимка. Имах само няколко изисквания: мъж на средна възраст, облечен в неподходящ костюм с няколко номера по-голям и в поза за „професионална студийна фотосесия“. За теста те го показаха на приятели и попитаха „как ви харесва?“
По време на процеса на разработване на дизайна съпругът ми трябваше да ляга на всеки половин час; хеликоптерът започна да лети. Паша се опита да отвори конзолата за разработчици до по-голямата част от екрана, докато завършваше интерфейса - за да защити очите си.
Действителни устройства
Вентилаторите и светлините бяха монтирани през твърдотелни релета, така че да не се включват веднага на пълна мощност - така че мощността да се увеличава паралелно с наблюдението.
Но ще говорим за това в следващата публикация, за хардуерната част на играта и действителното изграждане на сайта.
Остани настроен!
Други статии за мисията за унищожаване на сървъра
Източник: www.habr.com