Vi fortsetter å fortelle deg hvordan laseroppdraget vårt med ødeleggelse av serveren ble arrangert. Start i forrige .
Totalt hadde bakenden av spillet 6 arkitektoniske enheter, som vi vil analysere i denne artikkelen:
- Backend av spillenheter som var ansvarlige for spillmekanismer
- Backend- og sitedatautvekslingsbuss på VPS
- Oversetter fra backend-forespørsler (spillelementer) til Arduino og maskinvare på stedet
- Arduino, som var ansvarlig for å kontrollere reléene, mottok kommandoer fra oversetteren og gjorde selve arbeidet
- Faktiske enheter: vifte, girlandere, gulvlamper, etc.
- Frontend - selve Falcon-nettstedet, hvorfra spillere kontrollerte enheter
La oss gå gjennom hver av dem.
Backend av spillenheter
Bakenden ble implementert som en fjæroppstartsapplikasjon: den hadde flere hvilekontrollere, et websocket-endepunkt og tjenester med spilllogikk.
Det var bare tre kontrollere:
- Megatron. Den nåværende Megatron-siden ble sendt gjennom GET-forespørsler: før og etter at strømmen ble slått på. Laseren avfyrte gjennom POST-forespørselen.
- Kartlegge tilde-sider slik at de blir servert etter sidenavn. Tilde produserer sider for eksport ikke med originale navn, men med intern ID og samsvarsinformasjon.
- Captcha-kontroller for å betjene pseudo-høybelastningsserver-captcha.
Websocket-endepunkt ble brukt til å kontrollere gadgets: lamper, krans og bokstaver. Det ble valgt å synkront vise for alle spillere gjeldende status for enheten: om den er på eller av, aktiv eller ikke, hvilken farge på bokstaven som for øyeblikket lyser på veggen. For å gjøre oppgaven med å slå på laseren litt vanskeligere, la vi autorisasjon til kransen og laseren med samme innlogging og passord admin/admin.
Spillere kunne teste det ved å slå på kransen og gjenta det samme med laseren.
Vi valgte et så trivielt innlogging-passord-par for ikke å plage spillere med unødvendig valg.
For å gjøre oppgaven litt mer interessant ble objekt-IDer fra mongodb brukt som enhetsidentifikatorer i rommet.
ObjectId inneholder et tidsstempel: to tilfeldige verdier, hvorav den ene er tatt basert på enhetsidentifikatoren, og den andre basert på pid-en til prosessen som genererer den og tellerverdien. Jeg ønsket å lage identifikatorene generert med jevne mellomrom og med forskjellige pid-prosesser, men med en felles teller, slik at valget av en laserenhetsidentifikator skulle bli mer interessant. Men til slutt begynte alle med identifikatorer som bare var forskjellige i tellerverdien. Dette kan ha gjort trinnet for enkelt og krever ikke analyse av objectId-strukturen.
Oversetter fra backend-forespørsler
, som jobbet med tidtakere og oversatte dem fra spillabstraksjoner til en fysisk modell. For eksempel, "slå på gulvlampen" → "slå på relé N2."
Skriptet koblet til RabbitMQ-køen og overførte forespørsler fra køen til Arduino. Den implementerte også logikken til parallell lysbytte: sammen med noen enheter ble lyset på dem slått på, for eksempel da strøm først ble levert til Megatron, ble det opplyst med scenelys. Lysdesign for kinematografien av hele scenen er en egen historie om det store arbeidet til vår prosjektmedprodusent og produksjonsdesigner Ilya Serov, og vi vil fortelle om det i et eget innlegg.
Oversetteren var også ansvarlig for logikken ved å starte makuleringsmaskinen ved hjelp av en tidtaker og overføre bildet til TV-en: tidtakeren for å starte makuleringsmaskinen, en skrikende kapybara, en reklamefilm på slutten av spillet.
Hvordan logikken for å generere Megatron-tokenet var strukturert
Prøveskudd
Hvert 25. sekund ble det generert en ny token som kunne brukes til å slå på laseren i 10 sekunder med 10/255 kraft. Link til .
Laseren ble deretter avkjølt i 1 minutt - i løpet av denne tiden var den utilgjengelig og godtok ikke nye skuddforespørsler.
Denne kraften var ikke nok til å brenne gjennom tauet, men enhver spiller kunne skyte Megatron og se laserstrålen i aksjon.
MD5 hashing-algoritmen ble brukt til å generere tokenet. Og opplegget fungerte MD5 fra MD5 + teller + hemmelig for en kampbrikke og uten en hemmelighet for en testbrikke.
MD5 er en referanse til et kommersielt prosjekt som Pavel, vår backender, gjorde. For bare et par år siden brukte dette prosjektet MD5, og da han fortalte prosjektarkitekten at det var en utdatert krypteringsalgoritme, begynte de å bruke MD5 fra MD5. Siden vi bestemte oss for å gjøre et mest mulig noob-prosjekt, husket han alt og bestemte seg for å lage en liten referanse.
Kampskudd
Megatrons kampmodus er 100 % laserkraft på 3 watt. Dette er nok i 2 minutter for å brenne gjennom tauet som holdt vekten, for å bryte akvariet og oversvømme serveren med vann.
Vi la noen hint om prosjektets Github: nemlig tokengenereringskoden, hvorfra man kunne forstå at test- og kamptokenene genereres basert på den samme tellerindikatoren. Når det gjelder en kampbrikke, brukes i tillegg til tellerverdien også et salt, som er nesten helt igjen i historien om å endre denne hovedsaken, med unntak av de to siste karakterene.
Når du kjenner disse dataene, var det mulig å sortere gjennom de to siste symbolene i saltet og faktisk finne ut at tallene fra Lost, konvertert til det heksadesimale systemet, ble brukt for det.
Deretter måtte spillerne fange tellerverdien (ved å analysere testtokenet) og generere et kamptoken ved å bruke neste tellerverdi og saltet valgt i forrige trinn.
Telleren økte ganske enkelt for hvert testskudd og hvert 25. sekund. Vi skrev ikke om dette noe sted, det skulle være en liten spilloverraskelse.
Captcha-interaksjonstjeneste
I spillverdenen var dette den samme captchaen som måtte lastes inn for å slå på viften og åpne flipoveren med et hint. Ved siden av kameraet sto en bærbar PC med lastovervåking.
Jeg beregnet hva som skal vises i overvåking som gjeldende belastning: temperatur og CPU-vifte. Beregninger ble overført til tidsbasedatabasen og tegnet med grafana.
Hvis det i løpet av de siste 5 sekundene var mer enn 50 forespørsler om å vise captchaen, økte belastningen med et fast + tilfeldig antall trinn. Beregningen var at 100 % belastning kunne oppnås på to minutter.
Faktisk var det mer logikk i tjenesten enn det som ble vist i det siste spillet: vi plasserte skjermen på en slik måte at bare rotasjonen til CPU-viften var synlig.
I begynnelsen av oppdraget ønsket de å la Grafan være tilgjengelig fra Falcon-nettstedet. Men den inneholdt også springboot-beregninger fra backend-applikasjonsrapporten, som vi ikke hadde tid til å fjerne, så vi bestemte oss for å blokkere tilgangen til den. Og med rette - selv i begynnelsen av oppdraget, gjettet noen spillere at applikasjonen var skrevet i springboot-rammeverket og til og med gravde opp navnene på noen tjenester.
Hosting og databuss
Et verktøy for å overføre informasjon fra backend til nettstedet, VPS-serveren som RabbitMQ kjørte på.
Backend og databussen ble holdt på . Kraften var sammenlignbar med datamaskinen du så på skjermen: en 2-kjerners VPS med to gigabyte RAM. Tariffen ble belastet for ressurser, siden toppbelastningen var planlagt for kun noen få dager - dette gjør våre kunder som planlegger å laste VPS for en kort periode. Da viste det seg at belastningen var høyere enn vi forventet, og en fast takst ville vært mer lønnsomt. Hvis du gjør et oppdrag, velg linjetakstene .
For å beskytte serveren mot DDoSa brukte vi Cloudflare.
Det er verdt å si at VPS motsto alt med ære.
Arduino, som var ansvarlig for å kontrollere reléene, mottok kommandoer fra oversetteren og gjorde selve arbeidet
Dette er mer temaet for den neste artikkelen om maskinvaredelen av prosjektet: backend sendte ganske enkelt forespørsler om å slå på et spesifikt relé. Det skjedde slik at backend kjente nesten alle enhetene og forespørsler fra den så ut som "slå på denne enheten." Vi gjorde dette for tidlig testing av siden (vi hadde ennå ikke satt sammen alle Arduinoene og reléene), til slutt lot vi alt være slik.
Frontend
Vi laget raskt siden på tilde, det tok en arbeidsdag og sparte oss for 30 tusen på budsjettet.
I utgangspunktet tenkte vi bare å eksportere nettstedet og legge til logikken vi manglet, men vi møtte bruksvilkår som forbød oss å gjøre dette.
Vi var ikke klare til å bryte lisensen, så det var to alternativer: å implementere alt selv eller å kontakte Tilda direkte, snakke om prosjektet og be om tillatelse til å endre koden.
Vi valgte det andre alternativet, og de møtte oss ikke bare halvveis, men ga oss til og med et års gratis forretningskonto, noe vi er veldig takknemlige for. Det var veldig vanskelig å vise dem Sokols nettsteddesign.
Som et resultat la vi js-logikk til frontend for å sende forespørsler til elementære enheter, og endret litt stilene på knappene for å slå på og av spillelementer.
Nettstedsdesign
Søkenes historie, som er verdt et eget kapittel.
Vi ønsket å lage ikke bare et gammeldags nettsted, men et helt ekkelt nettsted som bryter med alle grunnleggende designregler. Samtidig var det viktig å opprettholde troverdigheten: det måtte ikke bryte ØNH-historien, demonstrere pretensiøsiteten til forfatteren, og spillere måtte tro at et slikt nettsted kunne eksistere og til og med bringe kunder. Og han tok den med! Mens spillet pågikk, ble vi kontaktet to ganger for å lage nettsider.
Først laget jeg designet selv, og prøvde å inkludere flere gifs og skinnende elementer. Men designermannen min gjennom 10 år så seg over skulderen og avfeide det som «for godt». For å bryte designregler må du kjenne dem.
Det er flere fargekombinasjoner som fremkaller en varig følelse av avsky: grønt og rødt med samme rikdom, grått og rosa, blått pluss brunt. Til slutt bestemte vi oss for en kombinasjon av rødt og grønt som basisfarger, la til gifs med en katt og valgte 3-4 bilder av Sokolov selv fra et arkivbilde. Jeg hadde bare noen få krav: en middelaldrende mann, iført en dårlig passende dress et par størrelser for stor og i en "profesjonell studiofotografering". For testen viste de det til venner og spurte "hvordan liker du det?"
Under designutviklingsprosessen måtte mannen min legge seg ned hver halvtime; helikopteret begynte å fly. Pasha prøvde å åpne utviklerkonsollen til det meste av skjermen mens han fullførte frontend - for å beskytte øynene.
Faktiske enheter
Viftene og lysene ble montert gjennom solid-state reléer slik at de ikke skulle skru seg på full effekt umiddelbart – slik at effekten skulle øke parallelt med overvåking.
Men vi skal snakke om dette i neste innlegg, om maskinvaredelen av spillet og selve konstruksjonen av nettstedet.
Følg med!
Andre artikler om søken etter å ødelegge serveren
Kilde: www.habr.com