Aurtengo maiatzean jokalari gisa parte hartu nuen . Jokalari-kopurua kopuru jakin batera iristen denean minutu gutxiro horietako batzuk βerortzenβ direla ohartu nintzen. Zorionez zuretzat (baina niretzat ez), deskonektatu zen jokalari horietako bat nintzen aldiro, nahiz eta konexio ona izan. Erronka pertsonal gisa hartu nuen hau eta arazoaren arrazoiak bilatzen hasi nintzen. Hiru astez arazketa, proba eta konponketa egin ondoren, azkenean konpondu zen akatsa, baina bidaia ez zen hain erraza izan.
Jokalari anitzeko jokoekin arazoak oso zailak dira arakatzea. Normalean sare-parametro oso zehatzetan eta joko-baldintza oso zehatzetan gertatzen dira (kasu honetan, 200 jokalari baino gehiago izatea). Eta arazoa erreproduzi daitekeen arren, ezin da behar bezala arakatu, eten-puntuak txertatzeak jokoa geldiarazten duelako, tenporizadoreak nahasten dituelako eta normalean konexioa denbora-muga eragiten duelako. Baina iraunkortasunari eta tresna zoragarri bati esker Zer gertatzen ari zen jakitea lortu nuen.
Laburbilduz, akats bat eta latentzia-egoeraren simulazioaren inplementazio osatugabe baten ondorioz, bezeroa batzuetan erloju-ziklo batean jokalariaren sarrera hautatze-ekintzekin osatutako sare-pakete bat bidali behar zuen egoera batean aurkitzen zen ( horri "mega-pakete" deitzen diogu). Orduan zerbitzariak sarrerako ekintza horiek guztiak behar bezala jaso ez ezik, gainerako bezero guztiei ere bidali behar dizkie. 400 bezero badituzu, hau azkar arazo bihurtzen da. Zerbitzarirako esteka azkar oztopatzen da, eta paketeak galtzen dira eta berriro eskatutako paketeen jauzi bat sortzen da. Sarrerako ekintza atzeratzeak are bezero gehiagok bidaltzen ditu megapaketeak, eta elur-jausiak are handiagoa izango du. Zorioneko bezeroek berreskuratzea lortzen dute; beste guztiak erortzen dira.
Arazoa nahiko oinarrizkoa zen eta 2 aste behar izan nituen konpontzeko. Nahiko teknikoa da, beraz, xehetasun tekniko mamitsuak azalduko ditut jarraian. Baina, lehenik eta behin, jakin behar duzu ekainaren 0.17.54an kaleratutako 4 bertsioaz geroztik, behin-behineko konexio-arazoen aurrean, jokalari anitzekoa egonkortu egin dela, eta ezkutatzeko atzerapenak askoz ere akats gutxiago izan direla (moteltze eta teletransportazio gutxiago). Borroka-lag ezkutatzeko modua ere aldatu dut eta horrek apur bat leunagoa egingo duela espero dut.
Jokalari anitzeko Mega Pack - Xehetasun Teknikoak
Besterik gabe, joko bateko jokalari anitzekoak honela funtzionatzen du: bezero guztiek jokoaren egoera simulatzen dute, jokalarien sarrera soilik jasoz eta bidaliz ("sarrera ekintzak" deitzen zaie. Sarrera-ekintzak). Zerbitzariaren zeregin nagusia transmititzea da Sarrera-ekintzak eta kontrolatu bezero guztiek ekintza berdinak egiten dituztela erloju-ziklo berean. Honi buruz gehiago irakur dezakezu mezuan .
Zerbitzariak zer ekintzei buruz erabaki behar duenez, jokalariaren ekintzak bide honetatik mugitzen dira gutxi gorabehera: jokalariaren ekintza -> joko bezeroa -> sarea -> zerbitzaria -> sarea -> joko bezeroa. Horrek esan nahi du jokalari bakoitzaren ekintza sarean zehar joan-etorria egin ondoren bakarrik egiten dela. Horregatik, jokoak izugarri motela dirudi, beraz, ia berehala jokoan jokalari anitzekoa sartu eta gero, atzerapenak ezkutatzeko mekanismo bat sartu zen. Atzerapena ezkutatzeak jokalarien sarrera simulatzen du beste jokalarien ekintzak eta zerbitzariaren erabakiak kontuan hartu gabe.
Factoriok joko-egoera du Jokoaren egoera txartelaren, jokalariaren, entitateen eta gainerako guztiaren egoera osoa da. Bezero guztietan deterministikoki simulatzen da zerbitzaritik jasotako ekintzen arabera. Joko-egoera sakratua da, eta inoiz zerbitzariaren edo beste edozein bezerorengandik desberdintzen hasten bada, dessinkronizazioa gertatzen da.
Baina Jokoaren egoera atzerapen egoera dugu Latentzia-egoera. Oinarrizko egoeraren azpimultzo txiki bat dauka. Latentzia-egoera ez da sakratua eta jokalarien sarreren arabera etorkizunean joko-egoeraren itxuraren irudia besterik ez du adierazten Sarrera-ekintzak.
Horretarako, sortutakoaren kopia bat gordetzen dugu Sarrera-ekintzak atzerapen-ilaran.
Hau da, bezeroaren aldean prozesuaren amaieran irudiak honelako itxura du:
- Guk aplikatzen dugu Sarrera-ekintzak jokalari guztiak Jokoaren egoera sarrera-ekintza hauek zerbitzaritik jasotzeko modua.
- Atzerapen-ilaratik dena kentzen dugu Sarrera-ekintzak, zerbitzariaren arabera, dagoeneko aplikatu zaie Jokoaren egoera.
- Ezabatu Latentzia-egoera eta berrezarri ezazu itxura berdina izan dezan Jokoaren egoera.
- Ekintza guztiak aplikatzen ditugu atzerapen-ilaratik Latentzia-egoera.
- Datuetan oinarrituta Jokoaren egoera ΠΈ Latentzia-egoera Jokalariari ematen diogu jokoa.
Hori guztia neurri guztietan errepikatzen da.
Zailegia? Ez lasai, hau ez da guztia. Interneteko konexio fidagarriak konpentsatzeko, bi mekanismo sortu ditugu:
- Tick ββgalduak: zerbitzariak hori erabakitzen duenean Sarrera-ekintzak jokoaren erritmoan exekutatu egingo da, orduan jaso ez badu Sarrera-ekintzak jokalariren batek (adibidez, atzerapena handitu delako), ez du itxarongo, baina bezero honi jakinaraziko dio "Ez dut kontuan hartu zure Sarrera-ekintzak, hurrengo barran gehitzen saiatuko naizβ. Hau egiten da jokalari baten konexioarekin (edo ordenagailuarekin) arazoak direla eta, maparen eguneratzea beste guztientzat moteldu ez dadin. Aipatzekoa da hori Sarrera-ekintzak ez dira baztertzen, alde batera utzi baizik.
- Joan-etorriko latentzia osoa: zerbitzariak bezero bakoitzaren eta zerbitzariaren arteko joan-etorriko latentzia zein den asmatzen saiatzen da. 5 segundorik behin, bezeroarekin latentzia berri bat negoziatzen du behar izanez gero (iraganean konexioak nola jokatu duen oinarrituta), eta joan-etorriko latentzia handitu edo murrizten du horren arabera.
Berez, mekanismo hauek nahiko sinpleak dira, baina elkarrekin erabiltzen direnean (konexio-arazoekin gertatu ohi dena), kodearen logika zaila bihurtzen da kudeatzeko eta ertz-kasu askorekin. Gainera, mekanismo hauek jokoan sartzen direnean, zerbitzariak eta atzerapen-ilarak behar bezala ezarri behar du berezia Sarrera Ekintza izeneko StopMovementInTheNextTick. Horri esker, konexioarekin arazoak izanez gero, pertsonaia ez da bere kabuz ibiliko (adibidez, tren baten aurrean).
Orain entitateen hautaketak nola funtzionatzen duen azaldu behar dizugu. Transmititutako motaetako bat Sarrera Ekintza entitateen hautaketaren egoeraren aldaketa da. Jokalaria zein entitateren gainean ari den esaten die guztiei. Imajina dezakezun bezala, bezeroek bidaltzen dituzten sarrerako ekintza ohikoenetako bat da, beraz, banda zabalera aurrezteko, ahalik eta leku gutxien okupatzeko optimizatu dugu. Funtzionatzen den modua da entitate bakoitza hautatzen den heinean, doitasun handiko mapa koordenatu absolutuak gorde beharrean, jokoak aurreko hautapenarekiko doitasun baxuko desplazamendu erlatiboa gordetzen duela. Honek ondo funtzionatzen du saguaren hautaketak aurreko hautapenetik oso hurbil egon ohi direlako. Horrek bi baldintza garrantzitsu planteatzen ditu: Sarrera-ekintzak Inoiz ez dira saltatu behar eta ordena egokian bete behar dira. Baldintza hauek betetzen dira Jokoaren egoera. Baina zereginaz geroztik Latentzia-egoera jokalariarentzat Β«nahiko itxura onaΒ» izatean, ez daude konforme atzerapen egoeran. Latentzia-egoera ez du kontuan hartzen , erloju-zikloak saltatzearekin eta joan-etorriko transmisio-atzerapenak aldatzearekin lotuta.
Dagoeneko asma dezakezu nora doan hau. Azkenean megapack arazoaren arrazoiak ikusten hasi gara. Arazoaren sustraia entitate hautatzeko logikak oinarritzen duela da Latentzia-egoera, eta egoera honek ez du beti informazio zuzena jasotzen. Beraz, megapakete bat honelako zerbait sortzen da:
- Jokalariak konexio arazoak ditu.
- Erlojuaren zikloak saltatzeko eta joan-etorriko transmisioaren atzerapena erregulatzeko mekanismoak sartzen dira jokoan.
- Atzerapen egoera ilarak ez ditu mekanismo hauek kontuan hartzen. Horrek ekintza batzuk lehenago kentzea edo ordena okerrean egitea eragiten du, okerrak direla eta Latentzia-egoera.
- Jokalariak konexio-arazo bat du eta, zerbitzaria atzemateko, 400 ziklo simulatzen ditu.
- Tick ββbakoitzean, ekintza berri bat sortzen da, entitate-hautapena aldatzen duena, eta zerbitzarira bidaltzeko prestatzen da.
- Bezeroak 400+ entitate-aldaketen mega-sorta bidaltzen du zerbitzarira (eta beste ekintzekin: tiro-egoerak, ibiltze-egoerak, etab. ere arazo hau jasan zuten).
- Zerbitzariak 400 sarrera-ekintza jasotzen ditu. Sarrerako ekintzarik ez saltatzeko baimenik ez dagoenez, bezero guztiei ekintza horiek egiteko agintzen die eta sarean zehar bidaltzen ditu.
Ironia da banda zabalera aurrezteko diseinatutako mekanismo batek sare-pakete erraldoiak sortzen amaitu zuela.
Arazo hau eguneratze- eta atzerapen-ilararen laguntza-kasu ertain guztiak konpondu ditugu. Nahiz eta denbora dezente behar izan, azkenean hack azkarretan fidatzea baino merezi izan zuen ongi egitea.
Iturria: www.habr.com