IPad-i ishte në shkallë të ulët: një histori debug WebRTC

Nëse nuk e dini se si funksionon p2claw, ia vlen të kontrollosh si funksionon blogu para se të zhytet në këtë.

Hapa një nga aplikacionet e mia p2klavike në iPad dhe mora një faqe bosh. E njëjta URL ishte duke punuar në Macin tim, kutinë time linux dhe telefonin tim. Në të njëjtin motor shfletuesi, i njëjti rrjet.

Si në një histori të mirë detektivi, ne dolëm me një grup të dyshuarish [iPad-i, pastaj WebKit, më pas Pllaka] dhe të gjithë dolën të pafajshëm. Pak a shumë. Ajo doli të jetë dy insekte me një jelek: një kod i fortë konstant në webrc-rs, dhe një vendim një-line dizajn në barutstop që ne gjetëm nëpërmjet kokëfortësi të thjeshtë. Ne kishim një punë rreth e rrotull të njëjtën ditë, por duke kuptuar atë që kishim bërë në fakt mori dy javë të tjera.

Program i ngarkuar në HTML për të ngjyrosur gjendjen e ngarkimit dhe pastaj të varur. Nuk pati gabime përkatëse konsole, u rregjistrua Punëtori i Shërbimit, dora e dorës në WebRTC përfundoi, kanali i të dhënave u hap [p.sh. gati. gati. Gjendja= “Hapu” , dhe pastaj asgjë. Shfletuesi dërgoi GET-in e parë të tij mbi kanalin e të dhënave dhe priti përgjithmonë përgjigjen.

Agjenti në anën tjetër mendoi se gjithçka ishte në rregull. Ajo kishte shërbyer përgjigjen dhe e shtyu bytesin në kanal. Ata nuk arritën kurrë në iPad.

Nëse kjo nuk do të ishte mjaft e ndërlikuar, do të ishte një heisenbug: nëse unë freskohem si i çmendur, faqja ndonjëherë do të ngarkuar.

Gjëja e parë e dobishme që ne bëmë ishte të futeshim në të dy skajet e lidhjes dhe të rreshtonim shkrimet me orë: çdo pjesë e kutisë të dërguar, çdo pjesë e shfletuesit të marrë, dhe, thelbësisht, sa të dhëna kishte kutia në bufferin e saj të jashtëm që priste të dorëzohej. Kjo na ndihmoi të kuptonim se ku të dhënat nuk ishin duke e bërë atë në anën tjetër.

Pasi kishim hedhur çdo gjë në dorë dhe duke përfshirë shtrëngimet e duarve, po kapnim kashtën. Kontrolluam disa limite specifike dhe stabilitet të dyfishtë të rrjetit.

Duhet të ishte diçka specifike për iPad-in, por nuk e kishim idenë se çfarë.

Për të kërkuar, kutia dërgoi tri pjesë: një titull 220 byte, një trup 7.874 byte dhe një bisht 199 byte. Instrumenti ynë i ri tregoi ngjitjen e bufferit të jashtëm të dërguesit në rreth 8 kb dhe ndalimin. Ajo po mbante trupin që kishte “pranuar” por nuk mund të merrte kurrë konfirmimin që kishte arritur. Kur itapa u fresko, pamë të njëjtin model identik.

Kanalet e të dhënave WebRTC garantojnë dorëzimin në krye të UDP-së së humbur, kështu që një pjesë e humbur bllokon mesazhet pasuese. Në iPad, në konsolën e shfletuesit, pamë saktësisht një pjesë që po merrej [ 220 byte header] dhe pastaj asgjë. Ne nuk e pamë trupin apo emrat e vegjël të kërkesave të mëposhtme.

Ne testuam në Safari në Mac, duke supozuar se çështja mund të jetë WebKit që kur ndodhi në çdo shfletues io-s [dhe të gjithë shfletuesit io-s janë webkit nën kapuç], por Mac ishte duke marrë pjesë 8kb dhe 11 kb pa hikup.

Pas dy orësh teorish në WebKit, kuptova se ndryshe nga Mek, iPad-i kishte bërë të mundur kalimin e gjakut.

Në shkallë të ulët është një VPN, dhe një VPN mbyll trafikun tuaj në një shtresë shtesë që lë më pak hapësirë në çdo paketë. Pra, përgjigjet e mëdha u prenë në më shumë, pjesë më të vogla në rrugën për iPad-in sesa në Mek. WebKit zbaton vetë kanalet e të dhënave, në hapësirën e përdoruesit, duke përfshirë riformimin e mesazheve të mëdha nga paketat që i mbajnë ato. Teoria jonë evoluoi drejt një insekti në mesazhin e webkitit përsëri.

I rregulluam mesazhet e kutisë në 800 byte, aq të vogla sa secili prej tyre hipi në një paketë të vetme dhe iPad e ngarkoi menjëherë, në një shkallë të vogël ose jashtë. U duk sikur çështja u mbyll [në fakt një përpjekje e parë në 1,200 bytes, të cilën Klod më ndihmoi ta llogaritja se duhet të shkonte, në mënyrë misterioze nuk funksionoi. Mbaje atë mendim.

Në të kaluarën, ne sapo kishim zbuluar se çështja ishte VPN, dhe përsëri ne i qëndruam teorisë sonë WebKit. Duke pasur parasysh kontekstin tonë bloat [si imi, ashtu edhe agjentët’, kjo është shqetësuese në epokën e AI në fund të fundit], zbulimi në shkallë të ulët u zhyt në teorinë e WebKit në vend që ta sfidonte atë. Ne mund të kemi shikuar në rrjet dhe dërguesin Wbrtc, por në vend të kësaj ne e morëm atë si një arsye më shumë që shfletuesi ishte në faj. Kështu që ne e shkruam incidentin si një insekt iOS Safari [paisja merr paketat, por kurrë nuk i rishtyp ato për aplikacionin ] dhe filluam të ndërtojmë një riprodhim të vetëm për ta provuar atë.

Për dy javët e ardhshme, insekti nuk u ripropozua me një dërgues në JavaScript, kështu që u kthyem tek një dërgues i bazuar në Webbc. Akoma asgjë. Ne përputhem me format dhe përmasat e kanaleve të të dhënave, dhe përdorëm një kompozues real si në Linux, ashtu edhe në iPad, me dhe pa shkallë. Ka dorëzuar çdo gjë, çdo herë. Përfundimisht na u desh të ri-lexonim provat tona [në fakt Antropic lëshoi Fible dhe unë e kisha atë të gërmonte shkrimet e Jsonl nga sesioni origjinal i debug].

Numrat vendimtarë ishin në kundërvënien e vetë WebRTC-së për Statats, të cilën e kanë dërguar klientët tanë tek konsola dhe që e kemi kapur në fotografitë e ekranit gjatë incidentit. Çifti kandidat i iPad-it ngriu në 2,144 bytes morën përmes 18 paketave, ndërsa kanali i të dhënave kishte dhënë pikërisht një mesazh [