Vi fortsætter med at fortælle dig, hvordan vores laser-quest med ødelæggelsen af serveren blev arrangeret. Start i forrige .
I alt havde backend af spillet 6 arkitektoniske enheder, som vi vil analysere i denne artikel:
- Backend af spilenheder, der var ansvarlige for spilmekanismer
- Backend og site dataudveksling bus på VPS
- Oversætter fra backend-anmodninger (spilelementer) til Arduino og hardware på stedet
- Arduino, som var ansvarlig for at styre relæerne, modtog kommandoer fra oversætteren og udførte selve arbejdet
- Faktiske enheder: ventilator, guirlander, gulvlamper osv.
- Frontend - selve Falcon-webstedet, hvorfra spillere styrede enheder
Lad os gennemgå hver af dem.
Backend af spilenheder
Backend'en blev implementeret som en fjederstartapplikation: den havde flere hvilecontrollere, et websocket-endepunkt og tjenester med spillogik.
Der var kun tre controllere:
- Megatron. Den aktuelle Megatron-side blev sendt gennem GET-anmodninger: før og efter tænding af strømmen. Laseren affyrede gennem POST-anmodningen.
- Kortlægning af tilde-sider, så de betjenes af sidenavn. Tilde producerer sider til eksport, ikke med originale navne, men med internt ID og compliance information.
- Captcha-controller til at betjene pseudo-high-load server-captcha.
Websocket-endepunkt blev brugt til at styre gadgets: lamper, guirlande og bogstaver. Det blev valgt til synkront at vise enhedens aktuelle status for alle spillere: om den er tændt eller slukket, aktiv eller ej, hvilken farve på bogstavet, der i øjeblikket lyser på væggen. For at gøre opgaven med at tænde laseren lidt sværere, tilføjede vi autorisation til guirlanden og laseren med samme login og adgangskode admin/admin.
Spillere kunne teste det ved at tænde for guirlanden og gentage det samme med laseren.
Vi valgte sådan et trivielt login-adgangskodepar for ikke at plage spillere med unødvendigt valg.
For at gøre opgaven lidt mere interessant blev objekt-id'er fra mongodb brugt som enhedsidentifikatorer i rummet.
ObjectId indeholder et tidsstempel: to tilfældige værdier, hvoraf den ene tages baseret på enhedsidentifikatoren, og den anden er baseret på pid'en for den proces, der genererer den, og tællerværdien. Jeg ønskede at lave identifikatorerne genereret med jævne mellemrum og med forskellige pid-processer, men med en fælles tæller, så valget af en laserenhedsidentifikator ville være mere interessant. Men i sidste ende startede alle med identifikatorer, der kun adskilte sig i tællerværdien. Dette kan have gjort trinnet for simpelt og ikke kræve analyse af objectId-strukturen.
Oversætter fra backend-anmodninger
, der arbejdede på timere og oversatte dem fra spilabstraktioner til en fysisk model. For eksempel "tænd gulvlampen" → "tænd relæ N2."
Scriptet sluttede sig til RabbitMQ-køen og overførte anmodninger fra køen til Arduino. Det implementerede også logikken i parallel lysskiftning: sammen med nogle enheder blev lyset på dem tændt, for eksempel, da strøm blev leveret til Megatron oprindeligt, blev det oplyst med scenelys. Lysdesign til kinematografien af hele scenen er en separat historie om det store arbejde fra vores projektco-producer og produktionsdesigner Ilya Serov, og vi vil fortælle om det i et separat indlæg.
Oversætteren var også ansvarlig for logikken i at starte makuleringsmaskinen ved hjælp af en timer og sende billedet til tv'et: timeren til at starte makuleringsmaskinen, en skrigende capybara, en reklamefilm i slutningen af spillet.
Hvordan logikken for at generere Megatron-tokenet var opbygget
Prøveskud
Hvert 25. sekund blev der genereret et nyt token, som kunne bruges til at tænde laseren i 10 sekunder ved 10/255 strøm. Link til .
Laseren kølede derefter ned i 1 minut - i løbet af denne tid var den utilgængelig og accepterede ikke nye skudanmodninger.
Denne kraft var ikke nok til at brænde gennem rebet, men enhver spiller kunne affyre Megatron og se laserstrålen i aktion.
MD5-hash-algoritmen blev brugt til at generere tokenet. Og ordningen lykkedes MD5 fra MD5 + tæller + hemmelighed for en kampbrik og uden en hemmelighed for en testbrik.
MD5 er en reference til et kommercielt projekt, som Pavel, vores backender, lavede. For blot et par år siden brugte dette projekt MD5, og da han fortalte projektarkitekten, at det var en forældet krypteringsalgoritme, begyndte de at bruge MD5 fra MD5. Da vi besluttede at lave det mest noob-projekt muligt, huskede han alt og besluttede at lave en lille reference.
Kampskud
Megatrons kamptilstand er 100 % laserkraft ved 3 watt. Dette er nok i 2 minutter til at brænde gennem rebet, der holdt vægten, for at bryde akvariet og oversvømme serveren med vand.
Vi efterlod flere hints om projektets Github: nemlig tokengenereringskoden, hvorfra man kunne forstå, at test- og kamptokens er genereret baseret på den samme tællerindikator. I tilfælde af en kampbrik bruges der udover tællerværdien også et salt, som er næsten helt tilbage i denne kernes ændringshistorie, med undtagelse af de to sidste tegn.
Ved at kende disse data var det muligt at sortere gennem de sidste 2 symboler i saltet og faktisk finde ud af, at tallene fra Lost, omregnet til det hexadecimale system, blev brugt til det.
Derefter skulle spillerne fange tællerværdien (ved at analysere testtokenet) og generere et kamptegn ved hjælp af den næste tællerværdi og saltet valgt i det foregående trin.
Tælleren steg simpelthen for hvert testskud og hvert 25. sekund. Vi skrev ikke om dette nogen steder, det skulle være en lille spiloverraskelse.
Captcha interaktionstjeneste
I spilverdenen var dette den samme captcha, der skulle indlæses for at kunne tænde blæseren og åbne flipoveren med et hint. Ved siden af kameraet var en bærbar computer med belastningsovervågning.
Jeg beregnede, hvad der skulle vises i overvågningen som den aktuelle belastning: temperatur og CPU-blæser. Metrikker blev overført til tidsbasedatabasen og tegnet med grafana.
Hvis der i de sidste 5 sekunder var mere end 50 anmodninger om at vise captchaen, så steg belastningen med et fast + tilfældigt antal trin. Beregningen var, at 100 % belastning kunne opnås på to minutter.
Faktisk var der mere logik i tjenesten, end der blev vist i det sidste spil: Vi placerede skærmen på en sådan måde, at kun rotationen af CPU-blæseren var synlig.
I begyndelsen af missionen ønskede de at lade Grafan være tilgængelig fra Falcons hjemmeside. Men den indeholdt også springboot-metrics fra backend-applikationsrapporten, som vi ikke havde tid til at rydde, så vi besluttede at blokere adgangen til den. Og med rette - selv i begyndelsen af questen gættede nogle spillere på, at applikationen var skrevet i springboot-rammen og gravede endda navnene op på nogle tjenester.
Hosting og databus
Et værktøj til at overføre information fra backend til webstedet, VPS-serveren som RabbitMQ kørte på.
Backend og databussen blev holdt på . Dens kraft var sammenlignelig med den computer, du så på skærmen: en 2-core VPS med to gigabyte RAM. Taksten blev opkrævet for ressourcer, da spidsbelastningen kun var planlagt til et par dage - det gør vores kunder, som planlægger at indlæse VPS i en kort periode. Så viste det sig, at belastningen var højere, end vi havde forventet, og en fast takst ville være mere rentabel. Hvis du laver en opgave, skal du vælge linjetaksterne .
For at beskytte serveren mod DDoSa brugte vi Cloudflare.
Det er værd at sige, at VPS modstod alt med ære.
Arduino, som var ansvarlig for at styre relæerne, modtog kommandoer fra oversætteren og udførte selve arbejdet
Dette er mere emnet for den næste artikel om hardwaredelen af projektet: backend sendte simpelthen anmodninger om at tænde et specifikt relæ. Det skete så, at backend'en kendte næsten alle entiteterne, og anmodninger fra den så ud som "tænd denne enhed." Vi gjorde dette til tidlig test af webstedet (vi havde endnu ikke samlet alle Arduino og relæer), til sidst forlod vi alt sådan.
Frontend
Vi lavede hurtigt siden på tilde, det tog en arbejdsdag og sparede os 30 tusind på vores budget.
Til at begynde med tænkte vi på blot at eksportere webstedet og tilføje den logik, vi manglede, men vi stødte ind i brugsbetingelser, der forbød os at gøre dette.
Vi var ikke klar til at overtræde licensen, så der var to muligheder: at implementere alt selv eller at kontakte Tilda direkte, tale om projektet og bede om tilladelse til at ændre koden.
Vi valgte den anden mulighed, og de mødte os ikke kun halvvejs, men gav os endda et års gratis virksomhedskonto, hvilket vi er dem meget taknemmelige for. Det var meget akavet at vise dem Sokols hjemmesidedesign.
Som et resultat har vi knyttet js-logik til frontend for at sende anmodninger til elementære enheder, og ændrede lidt stilen på knapperne til at tænde og slukke for spilelementer.
Webstedsdesign
Søgningers historie, som er et separat kapitel værd.
Vi ønskede ikke bare at skabe et gammeldags websted, men et helt ulækkert websted, der overtræder alle de grundlæggende regler for design. Samtidig var det vigtigt at bevare troværdigheden: det måtte ikke bryde ØNH-historien, demonstrere forfatterens prætentiøsitet, og spillere skulle tro på, at et sådant websted kunne eksistere og endda bringe kunder. Og han bragte den! Mens spillet stod på, blev vi kontaktet to gange for at lave hjemmesider.
Først lavede jeg designet selv og prøvede at inkludere flere gifs og skinnende elementer. Men min designermand gennem 10 år kiggede sig over skulderen og afviste det som "for godt". For at bryde designregler skal du kende dem.
Der er flere farvekombinationer, der fremkalder en varig følelse af afsky: grøn og rød af samme rigdom, grå og pink, blå plus brun. Til sidst besluttede vi os for en kombination af rød og grøn som basisfarver, tilføjede gifs med en kat og udvalgte 3-4 billeder af Sokolov selv fra et stockfoto. Jeg havde kun et par krav: en midaldrende mand, iført et dårligt passende jakkesæt et par størrelser for stort og i en "professionel studiefotografering". Til testen viste de det til venner og spurgte "hvordan kan du lide det?"
Under designudviklingsprocessen måtte min mand lægge sig ned hver halve time; helikopteren begyndte at flyve. Pasha forsøgte at åbne udviklerkonsollen til det meste af skærmen, mens han var færdig med frontend - for at beskytte sine øjne.
Faktiske enheder
Ventilatorerne og lygterne blev monteret gennem solid-state relæer, så de ikke ville tænde for fuld effekt med det samme – så effekten ville stige sideløbende med overvågningen.
Men vi vil tale om dette i det næste indlæg, om hardwaredelen af spillet og selve konstruktionen af webstedet.
Bliv hængende!
Andre artikler om søgen efter at ødelægge serveren
Kilde: www.habr.com