Pokračujeme ve vyprávění, jak byla uspořádána naše laserová výprava se zničením serveru. Začněte v předchozím .
Celkově měl backend hry 6 architektonických jednotek, které budeme analyzovat v tomto článku:
- Backend herních entit, které byly zodpovědné za herní mechanismy
- Backend a sběrnice pro výměnu dat na místě na VPS
- Překladač z backendových požadavků (herních prvků) do Arduina a hardwaru na místě
- Arduino, které bylo zodpovědné za ovládání relé, dostalo příkazy od překladače a provedlo skutečnou práci
- Skutečná zařízení: ventilátor, girlandy, stojací lampy atd.
- Frontend - samotný web Falcon, ze kterého hráči ovládali zařízení
Pojďme si projít každou z nich.
Backend herních entit
Backend byl implementován jako jarní spouštěcí aplikace: měl několik zbývajících řadičů, koncový bod websocket a služby s herní logikou.
Existovaly pouze tři ovladače:
- Megatron. Aktuální stránka Megatronu byla odeslána prostřednictvím požadavků GET: před a po zapnutí napájení. Laser vystřelil přes požadavek POST.
- Mapování stránek vlnovky tak, aby byly obsluhovány podle názvu stránky. Tilde vytváří stránky pro export nikoli s původními názvy, ale s interním ID a informacemi o shodě.
- Řadič captcha pro obsluhu captcha serveru s pseudo-vysokou zátěží.
Koncový bod Websocket byl použit k ovládání gadgetů: lamp, girland a písmen. Bylo zvoleno, aby synchronně zobrazovalo všem hráčům aktuální stav zařízení: zda je zapnuto nebo vypnuto, aktivní nebo ne, jaká barva písmene aktuálně svítí na zdi. Abychom trochu ztížili zapínání laseru, přidali jsme autorizaci girlandy a laseru se stejným loginem a heslem admin/admin.
Hráči si to mohli vyzkoušet zapnutím girlandy a to samé opakovat s laserem.
Zvolili jsme takovou triviální dvojici login-heslo, abychom hráče netrápili zbytečným výběrem.
Aby byl úkol trochu zajímavější, byly jako identifikátory zařízení v místnosti použity ID objektů z mongodb.
ObjectId obsahuje časové razítko: dvě náhodné hodnoty, z nichž jedna je převzata na základě identifikátoru zařízení a druhá na základě pid procesu, který jej generuje, a hodnoty čítače. Chtěl jsem vytvořit identifikátory generované v pravidelných intervalech a různými pid procesy, ale se společným čítačem, aby byl výběr identifikátoru laserového zařízení zajímavější. Všichni však nakonec začali s identifikátory, které se lišily pouze hodnotou čítače. To možná učinilo krok příliš jednoduchým a nevyžadoval analýzu struktury objectId.
Překladač z backendových požadavků
, který pracoval na časovačích a převedl je z herních abstrakcí do fyzického modelu. Například „zapni stojací lampu“ → „zapni relé N2“.
Skript se připojil k frontě RabbitMQ a přenesl požadavky z fronty do Arduina. Implementovala také logiku paralelního přepínání světel: spolu s některými zařízeními se na nich rozsvítilo světlo, například když bylo zpočátku napájení Megatronu, bylo osvětleno jevištním světlem. Světelný design pro kinematografii celé scény je samostatný příběh o skvělé práci našeho projektového koproducenta a produkčního designéra Ilji Serova, o kterém si povíme v samostatném příspěvku.
Překladatel měl na svědomí i logiku spouštění skartovačky pomocí časovače a přenosu obrazu do TV: časovač pro spuštění skartovačky, ječící kapybara, reklama na konci hry.
Jak byla strukturována logika pro generování tokenu Megatronu
Testovací výstřel
Každých 25 sekund byl vygenerován nový žeton a mohl být použit k zapnutí laseru na 10 sekund na výkon 10/255. Odkaz na .
Laser se poté 1 minutu ochladil - po tuto dobu byl nedostupný a nepřijímal nové požadavky na záběr.
Tato síla nestačila propálit lano, ale každý hráč mohl vypálit Megatron a vidět laserový paprsek v akci.
K vygenerování tokenu byl použit hashovací algoritmus MD5. A schéma vyšlo MD5 z MD5 + počítadlo + tajenka za bojový žeton a bez tajemství za zkušební žeton.
MD5 je odkaz na komerční projekt, který dělal Pavel, náš backender. Jen před pár lety tento projekt používal MD5, a když architektovi projektu řekl, že jde o zastaralý šifrovací algoritmus, začali používat MD5 z MD5. Protože jsme se rozhodli udělat co nejvíce noob projekt, pamatoval si vše a rozhodl se udělat malou referenci.
Bojová střela
Bojový režim Megatronu je 100% výkon laseru při 3 wattech. To stačí na 2 minuty k propálení lana, které drželo závaží, k rozbití akvária a zaplavení serveru vodou.
Na Githubu projektu jsme zanechali několik rad: jmenovitě kód pro generování tokenů, z něhož lze pochopit, že testovací a bojové tokeny jsou generovány na základě stejného indikátoru počítadla. V případě bojového tokenu se kromě hodnoty počítadla používá také sůl, která je téměř úplně ponechána v historii změn této podstaty, s výjimkou posledních dvou postav.
Při znalosti těchto údajů bylo možné protřídit poslední 2 symboly soli a vlastně zjistit, že na to byla použita čísla ze Ztracených převedená do šestnáctkové soustavy.
Poté museli hráči chytit hodnotu počítadla (analýzou testovacího žetonu) a vygenerovat bojový žeton pomocí další hodnoty žetonu a soli vybrané v předchozím kroku.
Počítadlo se jednoduše zvýšilo s každým zkušebním výstřelem a každých 25 sekund. Nikde jsme o tom nepsali, mělo to být malé herní překvapení.
Služba interakce captcha
V herním světě to byla stejná captcha, která se musela načíst, aby bylo možné zapnout ventilátor a otevřít flipchart s nápovědou. Vedle kamery byl notebook s monitorováním zátěže.
Počítal jsem, co se má zobrazit v monitorování jako aktuální zátěž: teplota a ventilátor CPU. Metriky byly přeneseny do databáze časové základny a nakresleny grafanou.
Pokud se za posledních 5 sekund objevilo více než 50 požadavků na zobrazení captcha, zatížení se zvýšilo o pevný + náhodný počet kroků. Výpočet byl takový, že 100% zatížení lze dosáhnout za dvě minuty.
Ve skutečnosti bylo ve službě více logiky, než bylo zobrazeno ve finální hře: monitor jsme umístili tak, aby bylo vidět pouze otáčení ventilátoru CPU.
Na začátku pátrání chtěli nechat Grafana přístupný z webu Falcon. Obsahoval ale také metriky springboot z reportu backendové aplikace, které jsme nestihli vyčistit, proto jsme se rozhodli k němu zablokovat přístup. A právem – už na začátku questu někteří hráči hádali, že je aplikace napsaná ve springboot frameworku a dokonce vyhrabali názvy některých služeb.
Hosting a datová sběrnice
Nástroj pro přenos informací z backendu na web, VPS server, na kterém RabbitMQ běžel.
Backend a datová sběrnice byly zachovány . Jeho výkon byl srovnatelný s počítačem, který jste viděli na obrazovce: 2jádrový VPS se dvěma gigabajty RAM. Tarif byl zpoplatněn za zdroje, protože špičková zátěž byla plánována jen na několik dní - to dělají naši klienti, kteří plánují krátkodobě zatížit VPS. Pak se ukázalo, že zatížení bylo vyšší, než jsme čekali, a fixní tarif by byl výhodnější. Pokud děláte quest, vyberte si linkové tarify .
K ochraně serveru před DDoSa jsme použili Cloudflare.
Sluší se říci, že VPS vše vydrželo se ctí.
Arduino, které bylo zodpovědné za ovládání relé, dostalo příkazy od překladače a provedlo skutečnou práci
To je více tématem dalšího článku o hardwarové části projektu: backend jednoduše odeslal požadavky na zapnutí konkrétního relé. Stalo se, že backend znal téměř všechny entity a požadavky z něj vypadaly jako „zapni tuto entitu“. Udělali jsme to pro předčasné testování webu (ještě jsme neměli smontovaná všechna Arduino a relé), nakonec jsme vše nechali tak.
Frontend
Stránky jsme vytvořili rychle na tilde, trvalo to jeden pracovní den a ušetřili nám 30 tisíc v rozpočtu.
Původně jsme mysleli na to, že prostě exportujeme web a přidáme logiku, která nám chybí, ale narazili jsme na podmínky použití, které nám to zakazovaly.
Nebyli jsme připraveni porušit licenci, takže byly dvě možnosti: implementovat vše sami nebo kontaktovat přímo Tildu, promluvit si o projektu a požádat o povolení ke změně kódu.
Zvolili jsme druhou možnost a nejenže nám vyšli vstříc, ale dokonce nám dali rok podnikatelského účtu zdarma, za což jim moc děkujeme. Bylo velmi nepříjemné ukázat jim design webových stránek Sokola.
V důsledku toho jsme k frontendu připojili logiku js pro odesílání požadavků na elementární zařízení a mírně změnili styly tlačítek pro zapínání a vypínání herních prvků.
Designové stránky
Historie rešerší, která stojí za samostatnou kapitolu.
Chtěli jsme vytvořit nejen staromódní web, ale naprosto ohavný, který porušuje všechna základní pravidla designu. Zároveň bylo důležité zachovat uvěřitelnost: muselo to neporušovat příběh ORL, demonstrovat domýšlivost autora a hráči museli věřit, že takový web může existovat a dokonce přivést klienty. A on to přinesl! Zatímco hra probíhala, byli jsme dvakrát kontaktováni, abychom vytvořili webové stránky.
Zpočátku jsem dělal design sám, snažil jsem se zahrnout více gifů a lesklých prvků. Ale můj 10letý manžel návrhář se ohlédl přes rameno a odmítl to jako „příliš dobré“. Chcete-li porušit pravidla designu, musíte je znát.
Existuje několik barevných kombinací, které vyvolávají trvalý pocit znechucení: zelená a červená stejné sytosti, šedá a růžová, modrá plus hnědá. Nakonec jsme se rozhodli pro kombinaci červené a zelené jako základní barvy, přidali gify s kočičkou a vybrali 3-4 fotky samotného Sokolova ze stock fotky. Měl jsem jen pár požadavků: muž středního věku, na sobě nepadnoucí oblek o pár čísel větší a v póze „profesionálního ateliérového focení“. Na zkoušku to ukázali přátelům a zeptali se: „Jak se vám to líbí?
Při vývoji návrhu si manžel musel každou půlhodinu lehnout, helikoptéra začala létat. Pasha se pokusil otevřít vývojářskou konzoli na většinu obrazovky, zatímco dokončoval frontend - aby si chránil oči.
Skutečná zařízení
Ventilátory a světla byly namontovány přes polovodičová relé, aby se okamžitě nezapnuly na plný výkon – aby se výkon zvyšoval souběžně s monitorováním.
Ale o tom si povíme v dalším příspěvku, o hardwarové části hry a samotné konstrukci webu.
Zůstaňte naladěni!
Další články o snaze zničit server
Zdroj: www.habr.com