Kaip „TeamViewer“ taip greitai?

Atsiprašome už ilgį, tai būtina.

Įvadas

Aš sukuriu programinę įrangą nuotoliniam darbalaukiui (tik pramogoms) „Windows Vista“ / 7 „C # 4.0“. Aš įveikiau pagrindines kliūtis: turiu patikimą UDP pranešimų sistemą, santykinai švarią programos dizainą, turiu veidrodžio tvarkyklę („DFMirage“ nemokama „DemoForge“ veidrodžio tvarkyklė), ir aš įgyvendinau NAT trasą visiems NAT tipams, išskyrus simetriškus NAT įmonių užkardos situacijas).

Kalbant apie ekrano perkėlimą / bendrinimą, dėl veidrodžio vairuotojo automatiškai pranešama apie pasikeitusias ekrano sritis, ir galiu paprasčiausiai susieti veidrodžio vairuotoją, kada nors keičiant ekrano bitmapą, į savo bitmap. Tada aš suspausti ekrano sritį kaip PNG ir siųsti jį iš serverio į savo klientą. Viskas atrodo gana gera, tačiau ji nėra pakankamai greita. Jis yra toks lėtas kaip VNC (beje, nenaudoju VNC protokolo, tik priskirtas mėgėjų protokolas).

Nuo lėtiausio nuotolinio darbalaukio programinės įrangos iki greičiausio sąrašo paprastai prasideda visi diegimai, pvz., „VNC“, ir tada eina į „Microsoft Windows“ nuotolinį darbalaukį ... ir tada ... „TeamViewer“. Ne visai tikri apie „CrossLoop“, „LogMeIn“ - aš jų nenaudojau, bet „TeamViewer“ yra beprotiškai greitas. Tai tiesiog pažodžiui gyvena. Komandos eilutėje paleidžiau tree komandą ir buvo atnaujinta 20 ms vėlinimu. Gebu naršyti internete vos kelis milisekundes lėčiau nei mano nešiojamuoju kompiuteriu. „Visual Studio“ slinkties kodas vertikaliai yra 50 ms. Pagalvokite, kaip patikimas „TeamViewer“ ekrano transliavimo sprendimas yra visa tai.

VNC naudoja apklausomis pagrįstus klausimynus, kad nustatytų ekrano pokyčius ir ekrano užfiksavimą naudojant pertvarą / palyginimą blogiausiu atveju. Geriausiu atveju jie naudoja veidrodžio tvarkyklę, pvz., DFMirage. Aš esu šiame lygyje. Ir jie naudoja kažką, vadinamą RFB protokolu.

Atrodo, kad „Microsoft Windows“ nuotolinis darbalaukis yra vienas žingsnis didesnis nei VNC. Iš kažkur StackOverflow girdėjau, kad „Windows“ nuotolinis darbalaukis nesiunčia ekrano bitų, bet faktinių braižymo komandų. Tai gana puikus, nes jis gali tiesiog siųsti paprastą tekstą (atkreipti šį stačiakampį su šia koordinatė ir dažyti jį šiuo gradientu)! Nuotolinis darbalaukis yra tikrai greitas - ir tai yra standartinis būdas dirbti iš namų. Jis naudoja kažką, vadinamą KPP.

Dabar TeamViewer yra man visiškai paslaptis. Matyt, jie išleido savo pirmąjį kodą 2 versijai (TeamViewer - versija 7, 2012 m. Vasario mėn.). Žmonės jį perskaito ir sakė, kad 2 versija yra nenaudinga - tai tik keletas patobulinimų, lyginant su VNC su automatiniu NAT judėjimu.

Bet 7 versija ... tai juokinga greitai. Aš turiu galvoje, jis veikia greičiau nei „Windows Remote Desktop“. Transliuoju „DirectX 3D“ žaidimus su „TeamViewer“ (1 fps, tačiau „Windows“ nuotolinis darbalaukis netgi neleidžia „DirectX“ paleisti).

Beje, „TeamViewer“ visa tai daro be veidrodinio vairuotojo. Galima įdiegti vieną, ir ji tampa šiek tiek greičiau.

Klausimas

Mano klausimas yra toks: kiek „TeamViewer“ taip greitai? Tai neturėtų būti įmanoma. Jei turite 1920–1080 raišką net 24 bitų gylyje (16 bitų gylis bus pastebimai negražus), tai vis dar yra 6,220,800 baitų. Net naudojant „libjpeg-turbo“ (viena iš sparčiausių JPG kompresijos bibliotekų, naudojamų didelėms korporacijoms), suspaudimas iki 30KB (net jei jis yra labai didelis) trunka daug laiko per „TeamViewer“ serverius („TeamViewer“ apeina korporacinį „Symmetric NAT“, tiesiog perkeliant srautą per savo serverius ). Ir suspausti „libjpeg-turbo“ reikia laiko suspausti. Aukštos kokybės JPG suspaudimas užtrunka 175 milisekundes, kad galėtumėte iki 1920 m. Ir šis skaičius padidėja, jei kompiuteris įjungia „Atom“ procesorių. Aš nesuprantu, kaip „TeamViewer“ taip gerai optimizavo ekrano perdavimą. Vėlgi, smulkūs vaizdai gali būti labai suspausti, tačiau suspausti užtrunka bent dešimtys milisekundžių. Dideliems atvaizdams nereikia laiko suspausti, bet praeiti ilgą laiką. Kažkaip „TeamViewer“ užbaigia šį procesą, kad gautų apie 20-25 kadrų per sekundę. Naudojau tinklo monitorių, o „TeamViewer“ vis dar yra abejingas 500 Kbps ir 1 Mbps (VNC programinės įrangos palieka kelias sekundes šiuo perdavimo greičiu). Bandymo tree komanda komanda TeamViewer gavo gaunamus duomenis 1 Mbps greičiu ir vis dar atliko 5-6 kadrus per sekundę. VNC ir nuotolinio darbalaukio nėra. Taigi, kaip?

Atsakymai bus šiek tiek sudėtingi ir sudėtingi, todėl, jei tai tik pasakysite, neskelbkite savo $ 0,02, nes jie naudoja UDP vietoj TCP (manote, kad iš tikrųjų jie taip pat sėkmingai naudoja TCP).

Tikiuosi, kad „StackOverflow“ yra „TeamViewer“ kūrėjas.

Galimi atsakymai

Bus atnaujinta po to, kai žmonės atsakys.

  • Mano pirmoji mintis yra ta, kad „TeamViewer“ turi labai puikų tinklo valdymą. Pavyzdžiui, jie nutraukia didelius paketus tik pagal MTU dydį ir niekada neišleidžia laiko kelionei. Jie tikriausiai turi visus išgalvotas kabliukus, skirtus ekrano pokyčiams aptikti, ir labai greitai palyginti XOR vaizdus.
138
29 февр. nustatė Jasonas , vasario 29 d 2012-02-29 15:06 '12, 15:06 2012-02-29 15:06
@ 5 atsakymai

Svarbiausia čia yra tai, kad nenorite perduoti statinių vaizdų, bet tik keisti vaizdus, ​​kurie iš esmės yra panašūs į vaizdo srautą .

Mano geriausias spėjimas yra labai efektyvus (ir labai specializuotas ir optimizuotas) judesio kompensavimo algoritmas, nes didžioji dalis faktinių viso darbalaukio naudojimo pokyčių yra tiesinis elementų judėjimas (slinkimas, judantys >

„DirectX 3D“ veikimas 1 FPS, atrodo, tam tikru mastu palaiko mano prielaidas.

70
29 февр. Atsakymą pateikė Kimvais 29 vasario mėn. 2012-02-29 15:46 '12, 15:46, 2012-02-29 15:46

maršruto per „TeamViewer“ serverį užtruks ilgai („TeamViewer“ apeina įmonės „Symmetric NAT“ tiesiog priartindama srautą per savo serverius)

Jūs pastebėsite, kad „TeamViewer“ retai turi persiųsti srautą per savo serverius. TeamViewer įsiskverbia į NAT ir tinklus, sudėtingas NAT, naudodamasis NAT traversal (manau, kad tai UDP skylės perforacija , pvz., „ Google libjingle“ ).

border=0

Jie naudoja savo serverius, kad vidutinis žmogus atliktų rankų paspaudimą ir užmegztų ryšį, tačiau didžiąją laiko dalį santykiai tarp kliento ir serverio bus P2P (geriausias atvejis, kai sėkmingai pakratoma rankomis). Jei NAT trasos nepavyksta, „TeamViewer“ iš tiesų perduos srautą per savo serverius.

Aš jį matė tik tada, kai klientas buvo už dvigubo NAT.

17
31 марта '12 в 22:59 2012-03-31 22:59 atsakymą pateikė Jamie Edwards kovo 31 d. 12 d., 22:59 val. 2012-03-31 22:59

Truputį pavėluotas atsakymas, bet aš siūlau jums pažvelgti į mažai žinomą projektą kodų sistemoje, vadinamoje „ ConferenceXP“

ConferenceXP yra atviro kodo mokslinių tyrimų platforma, teikianti paprastą, lanksčią ir išplėstinę konferenciją ir bendradarbiavimą naudojant didelės spartos tinklą ir patobulintas „Microsoft Windows“ multimedijos galimybes. „ConferenceXP“ padeda mokslininkams ir mokytojams kurti novatoriškas programas ir sprendimus, kurie transliuoja garso ir vaizdo kokybę, palaikant realiuoju laiku vykdomą bendradarbiavimą ir nuotolinį mokymąsi.

Pateikiamas pilnas šaltinis (tai didžiulis!). Jis įgyvendina RTP protokolą .

12
08 дек. Simon Mourier atsakymas 08 Dec 2012-12-08 12:40 '12 12:40 2012-12-08 12:40

Tai skamba kaip vaizdo transliacija daugiau nei srautinio vaizdo, kaip kažkas pasiūlė. JPEG / PNG suspaudimas nėra skirtas šiems greičio tipams, todėl pamiršite juos.

Įsivaizduokite, kad jūsų sistemoje yra įrašymo kodekas, kuris gali įrašyti gaunamą vaizdo įrašą (ekraną) realiu laiku. Galbūt šiek tiek kaip Fraps. Tada įsivaizduokite vaizdo atkūrimo kodeką iš kitos pusės (nuotolinis klientas). Kadangi HD įrašymo įrenginiai gali tai padaryti (tiesioginis įrašymas ir net realaus laiko atkūrimas iš tos pačios HD), taip galite. „HD“ tikrai negali pristatyti vaizdų greičiau, nei galite perskaityti savo ekraną, todėl tai nėra kliūtis. Trūkumas yra vaizdo kodekai. Jūs pastebėsite, kad koduotojas turi daug daugiau problemų nei dekoderis, nes visi dekoderiai dažniausiai yra laisvi.

Aš tiesiog nesakau; Aš pats naudoju DirectShow koduoti vaizdo failą ir tai nėra realiu laiku. Tačiau, atsižvelgiant į teisingą kodeką, esu įsitikinęs, kad jis gali dirbti.

5
23 нояб. atsakymą pateikė Ruud van Gaal, lapkričio 23 d. 2012-11-23 22:53 '12 10:53 val. 2012-11-23 22:53

Keista. tačiau, mano nuomone, „TeamViewer“ nėra greitesnis / greitesnis nei VNC, lengviau konfigūruoti. Turiu win-boxen porą, kurioje turiu VNC per OpenVPN (taip yra ir kitas viršutinis sluoksnis), ir kad pigiame kabelyje (512), ir manau, kad „TightVNC“ yra geriau sukonfigūruotas nei „TeamViewer“ tas pats >

Kas mus veda į:

  • Kodėl nenaudojate VNC? Yra daug atviro kodo sprendimų ir „Tight“, tikriausiai dabar šio žaidimo viršuje.

  • Patobulinti VNC diegimai naudoja nuostolingą suspaudimą ir, atrodo, turi geresnių rezultatų nei jūsų PNG pasirinkimas. Be to, IIRC likusios naudingosios apkrovos dalis taip pat sutraiškoma naudojant zlib. „Bothj Tight“ ir „UltraVNC“ yra labai optimizuoti, ypač >

  • Jei laimėjimas yra jūsų pagrindinis tikslas, KPP gali būti geriausias variantas ir atviro kodo diegimas (rdesktop)

  • Jei * nix boxen yra jūsų pagrindinis tikslas, „NX“ gali būti geriausias variantas ir turi atviro kodo diegimą („FreeNX“, nors ir ne taip optimizuotas kaip „NoMachine“ produktas).

Jei JPEG suspaudimas yra jūsų algoritmo veikimo problema, esu tikras, kad vaizdų palyginimas vis tiek lems prastą našumą. Tikiuosi, kad kiekviena konkreti situacija naudoja geriausio atvejo suspaudimą, t.y. Su didelių rėmelių nuostoliais, kai kurie mažesni, greitai ir nešvarūs vidiniai nuostoliai, palyginkite bitų atvaizdus ir siunčia tik skirtingus rūšiavimo ir kitų optimizavimo gudrybių krūva.

Ir daugelis iš šių triukų turėtų būti „Tight“> 2.0, nes, mano patirtis, vėl ji yra pranašesnė už „TeamViewer“, „YMMV“.

Be to, pasirenkant sukomponuotą JIT veikimo laiką, panašų į C ++, galite atlikti savo našumo ribą, ypač mašinose su ribotais fiziniais sugebėjimais (kai įjungiami >

2
08 окт. Atsakymas, kurį pateikė Bojan Markovic 08 spalis 2012-10-08 10:04 '12, 10:04, 2012-10-08 10:04