Continuăm să vă spunem cum a fost aranjată căutarea noastră laser cu distrugerea serverului. Începe cu precedentul .
În total, backend-ul jocului a avut 6 unități arhitecturale, pe care le vom analiza în acest articol:
- Backend al entităților de joc care erau responsabile pentru mecanismele jocului
- Backend și magistrală de schimb de date de site pe VPS
- Traducător de la solicitările backend (elementele jocului) la Arduino și hardware pe site
- Arduino, care era responsabil pentru controlul releelor, a primit comenzi de la traducător și a făcut munca efectivă
- Dispozitive reale: ventilator, ghirlande, lămpi de podea etc.
- Frontend - site-ul Falcon în sine, de pe care jucătorii controlau dispozitivele
Să trecem prin fiecare dintre ele.
Backend-ul entităților de joc
Backend-ul a fost implementat ca o aplicație Spring Boot: avea mai multe controlere de odihnă, un endpoint websocket și servicii cu logica de joc.
Erau doar trei controlori:
- Megatron. Pagina actuală Megatron a fost trimisă prin solicitări GET: înainte și după pornirea alimentării. Laserul a declanșat prin cererea POST.
- Maparea paginilor tilde astfel încât acestea să fie difuzate după numele paginii. Tilde produce pagini pentru export nu cu nume originale, ci cu ID intern și informații de conformitate.
- Controler Captcha pentru a servi captcha de server pseudo-încărcare.
Punctul final Websocket a fost folosit pentru a controla gadget-uri: lămpi, ghirlande și litere. S-a ales să afișeze sincron tuturor jucătorilor starea curentă a dispozitivului: dacă este pornit sau oprit, activ sau nu, ce culoare a literei este luminată în prezent pe perete. Pentru a face sarcina de a porni laserul un pic mai dificilă, am adăugat autorizație ghirlandei și laserului cu aceeași autentificare și parolă admin/admin.
Jucătorii îl puteau testa pornind ghirlanda și repetă același lucru cu laserul.
Am ales o astfel de pereche de autentificare-parolă banală pentru a nu chinui jucătorii cu selecții inutile.
Pentru a face sarcina un pic mai interesantă, ID-urile obiectelor de la mongodb au fost folosite ca identificatori de dispozitiv în cameră.
ObjectId conține un marcaj temporal: două valori aleatorii, dintre care una este luată pe baza identificatorului dispozitivului, iar a doua pe baza codului pid al procesului care îl generează și a valorii contorului. Am vrut să fac identificatorii generați la intervale regulate și cu procese pid diferite, dar cu un contor comun, astfel încât să fie mai interesantă selecția unui identificator de dispozitiv laser. Cu toate acestea, până la urmă, toată lumea a început cu identificatori care diferă doar prin valoarea contorului. Acest lucru poate să fi făcut pasul prea simplu și să nu fi necesitat analiza structurii objectId.
Traducător din solicitările backend
, care a lucrat la cronometre și le-a tradus din abstracțiile jocurilor într-un model fizic. De exemplu, „porniți lampada de podea” → „porniți releul N2”.
Scriptul s-a conectat la coada RabbitMQ și a transferat cererile din coadă la Arduino. De asemenea, a implementat logica comutării paralele a luminii: împreună cu unele dispozitive, lumina de pe ele a fost aprinsă, de exemplu, când a fost furnizată inițial energie către Megatron, a fost iluminată cu lumină de scenă. Designul de iluminat pentru cinematografia întregii scene este o poveste separată despre marea muncă a coproducătorului nostru de proiect și designer de producție Ilya Serov și vom spune despre aceasta într-o postare separată.
Translatorul a fost responsabil și de logica lansării tocătorului folosind un cronometru și transmiterii imaginii către televizor: temporizatorul pentru lansarea tocătorului, un capibară care țipă, o reclamă la sfârșitul jocului.
Cum a fost structurată logica pentru generarea jetonului Megatron
Lovitură de probă
La fiecare 25 de secunde a fost generat un nou jeton și putea fi folosit pentru a porni laserul timp de 10 secunde la putere 10/255. Link către .
Laserul s-a răcit apoi timp de 1 minut - în acest timp a fost indisponibil și nu a acceptat noi solicitări de fotografiere.
Această putere nu era suficientă pentru a arde prin frânghie, dar orice jucător putea să tragă Megatron și să vadă raza laser în acțiune.
Algoritmul de hashing MD5 a fost folosit pentru a genera simbolul. Și schema a funcționat MD5 din MD5 + contor + secret pentru un jeton de luptă și fără un secret pentru un jeton de test.
MD5 este o referire la un proiect comercial pe care l-a realizat Pavel, backenderul nostru. Cu doar câțiva ani în urmă, acest proiect a folosit MD5, iar când i-a spus arhitectului proiectului că este un algoritm de criptare învechit, au început să folosească MD5 de la MD5. Din moment ce am decis să facem cel mai noob proiect posibil, el și-a amintit totul și a decis să facă o mică referință.
Lovitură de luptă
Modul de luptă al lui Megatron este 100% putere laser la 3 wați. Este suficient timp de 2 minute pentru a arde prin frânghia care a ținut greutatea, pentru a sparge acvariul și a inunda serverul cu apă.
Am lăsat câteva indicii despre Github-ul proiectului: și anume, codul de generare a jetoanelor, din care se poate înțelege că jetoanele de testare și de luptă sunt generate pe baza aceluiași indicator de contor. În cazul unui jeton de luptă, pe lângă valoarea contorului, se mai folosește și o sare, care este aproape complet lăsată în istoria schimbării acestui esențial, cu excepția ultimelor două personaje.
Cunoscând aceste date, a fost posibil să sortăm ultimele 2 simboluri ale sării și să aflăm efectiv că numerele din Lost, convertite în sistemul hexazecimal, au fost folosite pentru aceasta.
Apoi, jucătorii trebuiau să prindă valoarea contorului (prin analizarea jetonului de test) și să genereze un jeton de luptă folosind următoarea valoare a contorului și sarea selectată la pasul anterior.
Contorul a crescut pur și simplu cu fiecare lovitură de test și la fiecare 25 de secunde. Nu am scris despre asta nicăieri, trebuia să fie o mică surpriză de joc.
Serviciu de interacțiune Captcha
În lumea jocurilor, acesta era același captcha care trebuia încărcat pentru a porni ventilatorul și a deschide flipchart-ul cu un indiciu. Lângă cameră era un laptop cu monitorizare a încărcării.
Am calculat ce să afișez în monitorizare ca sarcină curentă: temperatura și ventilatorul CPU. Metricurile au fost transferate în baza de date a bazei de timp și desenate de grafana.
Dacă în ultimele 5 secunde au existat mai mult de 50 de solicitări de afișare a captcha-ului, atunci încărcarea a crescut cu un număr fix + aleatoriu de pași. Calculul a fost că sarcina de 100% ar putea fi atinsă în două minute.
De fapt, a fost mai multă logică în serviciu decât a fost afișată în jocul final: am plasat monitorul în așa fel încât să fie vizibilă doar rotația ventilatorului CPU.
La începutul căutării au vrut să lase Grafan accesibil de pe site-ul Falcon. Dar conținea și valorile springboot din raportul aplicației backend, pe care nu am avut timp să le ștergem, așa că am decis să blocăm accesul la el. Și pe bună dreptate - chiar și la începutul misiunii, unii jucători au ghicit că aplicația a fost scrisă în cadrul Springboot și chiar au dezgropat numele unor servicii.
Gazduire si magistrala de date
Un instrument pentru transferul de informații de la backend pe site, serverul VPS pe care rula RabbitMQ.
Backend-ul și magistrala de date au fost menținute . Puterea sa era comparabilă cu computerul pe care l-ai văzut pe ecran: un VPS cu 2 nuclee și doi gigaocteți de memorie RAM. Tariful a fost perceput pentru resurse, deoarece sarcina maximă a fost planificată pentru doar câteva zile - asta fac clienții noștri care intenționează să încarce VPS pentru o perioadă scurtă de timp. Apoi s-a dovedit că sarcina era mai mare decât ne așteptam, iar un tarif fix ar fi mai profitabil. Dacă faceți o căutare, alegeți tarifele liniei .
Pentru a proteja serverul de DDoSa, am folosit Cloudflare.
Merită spus că VPS-ul a rezistat la toate cu onoare.
Arduino, care era responsabil pentru controlul releelor, a primit comenzi de la traducător și a făcut munca efectivă
Acesta este mai degrabă subiectul următorului articol despre partea hardware a proiectului: backend-ul a trimis pur și simplu solicitări de a porni un anumit releu. S-a întâmplat că backend-ul cunoștea aproape toate entitățile și solicitările de la acesta păreau „porniți această entitate”. Am făcut asta pentru testarea timpurie a site-ului (nu asamblasem încă toate Arduino-urile și releele), până la urmă am lăsat totul așa.
În față
Am creat rapid site-ul pe tilde, a durat o zi lucrătoare și ne-a economisit 30 de mii din bugetul nostru.
Inițial, ne-am gândit să exportăm site-ul și să adăugăm logica care ne lipsea, dar ne-am întâlnit cu condiții de utilizare care ne-au interzis să facem acest lucru.
Nu eram pregătiți să încălcăm licența, așa că existau două opțiuni: să implementăm totul singuri sau să o contactăm direct pe Tilda, să vorbim despre proiect și să cerem permisiunea de a schimba codul.
Am ales a doua variantă și nu doar că ne-au întâlnit la jumătatea drumului, ci chiar ne-au oferit un an de cont gratuit de afaceri, fapt pentru care le suntem foarte recunoscători. A fost foarte ciudat să le arăt designul site-ului web al lui Sokol.
Ca rezultat, am atașat logica js la interfață pentru trimiterea de solicitări către dispozitivele elementare și am schimbat ușor stilurile butoanelor pentru pornirea și dezactivarea elementelor de joc.
Proiectare site web
Istoria căutărilor, care merită un capitol separat.
Am vrut să creăm nu doar un site de modă veche, ci unul absolut dezgustător, care încalcă toate regulile de bază ale designului. În același timp, era important să se mențină credibilitatea: trebuia să nu rupă povestea ORL, să demonstreze pretenția autorului, iar jucătorii ar trebui să creadă că un astfel de site ar putea exista și chiar să aducă clienți. Și l-a adus! În timp ce jocul se desfășura, am fost contactați de două ori pentru a crea site-uri web.
La început am făcut singur designul, încercând să includ mai multe gif-uri și elemente strălucitoare. Dar soțul meu designer de 10 ani s-a uitat peste umăr și a respins-o drept „prea bună”. Pentru a încălca regulile de proiectare, trebuie să le cunoașteți.
Există mai multe combinații de culori care trezesc un sentiment de dezgust de durată: verde și roșu de bogăție egală, gri și roz, albastru plus maro. La final, ne-am stabilit pe o combinație de roșu și verde ca culori de bază, am adăugat gif-uri cu o pisică și am selectat 3-4 fotografii cu Sokolov însuși dintr-o fotografie de stoc. Aveam doar câteva cerințe: un bărbat de vârstă mijlocie, purtând un costum nepotrivit cu câteva mărimi prea mari și într-o ipostază de „ședință foto de studio profesională”. Pentru test, l-au arătat prietenilor și l-au întrebat „cum îți place?”
În timpul procesului de dezvoltare a designului, soțul meu a trebuit să se întindă la fiecare jumătate de oră; elicopterul a început să zboare. Pasha a încercat să deschidă consola pentru dezvoltatori pe cea mai mare parte a ecranului în timp ce termina de terminat front-end - pentru a-și proteja ochii.
Dispozitive reale
Ventilatoarele și luminile au fost montate prin relee cu stare solidă, astfel încât să nu se pornească imediat la putere maximă - astfel încât puterea să crească în paralel cu monitorizarea.
Dar despre asta vom vorbi în următoarea postare, despre partea hardware a jocului și construcția efectivă a site-ului.
Rămâneţi aproape!
Alte articole despre încercarea de a distruge serverul
Sursa: www.habr.com