Pred casom som napisal nieco o tom, co to LBX je, ako to funguje a ako to priblizne rozchodit. Odvtedy som vsak zacal remotne spustanie vyuzivat coraz viac, preto som zacal LBX skumat hlbsie. Tento clanok volne nadvazuje na prvy clanok o LBX.
Vzdialene spustanie grafickych aplikacii nie je vobec nova vec. Prve pokusy so vzdialenym zobrazovanim grafickych aplikacii boli na MIT (ak sa dobre pamatam) niekedy v roku 1984, kedy ho tamojsi profesori pouzivali na nazornu vyuku programovania. Principialne to fungovalo asi tak, ze program bezal na centralnom vykonnom servri, pricom kazdemu studentovi sa na obrazovke zobrazoval vystup a mohol ho riadit. Uz tu sa objavila architektura klient-server, ktora sa systemom X-Window taha dodnes. V tej dobe sa jednalo o protokol X1, avsak uz v roku 1987 bola vydana 11. verzia protokolu nazvana X11 (ktora je planovana aj ako finalna verzia, na ktorej sa nebude nic menit a oznacenie X11 sa stalo nazvom protokolu).
Aplikacie vyuzivajuce k zobrazovaniu X-Window server funguju na tom principe, ze posielaju serveru prikazy, atomy a okna, ktore maju nejaky content, ten ich zobrazuje. Aby sa ale aplikacie dali ovladat, posiela X server naspat aplikaciam eventy, ktore mozu, ale nemusia aplikacie akceptovat. Tento protokol je do znacnej miery pomaly a tazkopadny, vyzaduje velku reziu (specialne niektore pripady, ako vytvorenie aplikacneho okna a podobne). Toto zacalo byt s nastupom grafickych toolkitov, ako GTK+ a Qt velmi velkym problemom, pretoze tieto toolkity, aj ked boli stale pouzitelne po sieti, boli pisane hlavne na beh na lokalnom pocitaci, preto nebrali ohlad na objem prenasanych dat.
Medzicasom sa na trhu objavili Windows, ktore nemali ziadnu moznost spustat graficke (a vlastne ani konzolove) aplikacie nadialku. Istym riesenim situacie vo Windows sa stal protokol VNC, ktory implementoval vzdialeny framebuffer (obraz sa prenasal v malych stvorcekoch po sieti na vzdialeny pocitac a tam sa opat skladal). Toto riesenie bolo pre Windows vhodne, avsak bolo neefektivne, pretoze prenasalo aj relativne nepotrebny obraz (pracovna plocha, dekoracie okien, kurzor a pod.). Jeho nasadenie na Windows vsak preniklo aj do sfery UNIXu a vznikli vsemozne implementacie X11VNC. Vo svete UNIXu vsak toto riesenie bolo viacmenej nesystemove, pretoze vytvaralo sietovu implementaciu sietovo orientovaneho protokolu.
Problem s velmi nizkou rychlostou samotneho X11 si vsimli aj ludia okolo X11 a tak sa vo verzii X11R4 dostal do vyvojoveho stromu X servera balik LBX (Low Bandwidth X), ktory bol dostupny ako patch uz davnejsie. Princip LBX bol jednoduchy: komunikacia medzi klientom a serverom sla cez LBX proxy, ktore vykonavalo cacheovanie obsahu atomov, pixmap, celych objektovych struktur, pri prenose tieto data komprimovalo a zefektivnovalo niektore operacie, cim sa celkovy beh X aplikacii urychlil. Cielom LBX boli hlavne pomale modemove pripojenia a pripojenia s vysokou latenciou, kde sa ukazala vyhodnost nasadenia LBX.
Po teoretickom uvode maly prakticky priklad. Napisal som skript, ktory zjednodusuje spustenie X aplikacie cez LBX a vykonava niekolko hlavnych ukonov, ktore su potrebne
- v pripade, ze medzi lokalnym a vzdialenym pocitacom este pre aktualneho uzivatela neexistuje spojenie s LBX forwardom, vytvori ho
- umozni kopirovanie .Xauthority - suboru, ktory zabezpecuje autentifikaciu X klientov voci serveru
- korektne nastavi LBXproxy a prostredie pre beh aplikacie
Skripty je mozne stiahnut [odtialto].
lbxexec patri na lokalny pocitac, lbxserver patri na pocitac vzdialeny. Oba skripty musia mat v domovskom adresari subor .lbxrc.
Pre server vyzera takto:
#.lbxrc server
local_X_display=:10 # display, na ktory sa budu konektovat X aplikacie
lbx_X_display=:63 # display, na ktory sa bude konektovat LBX
Pre klienta vyzera takto:
#.lbxrc client
lbx_X_display=:63 # display, ktory sa bude forwardovat cez SSH
remote_host=user@host # defaultny uzivatel a host pre spustanie aplikacii
Hodnota premennej lbx_X_display musi byt na klientovi a na serveri rovnaka, co v podstate znamena, ze klient a server moze mat konfiguracne subory uplne identicke.
lbxexec ma nasledovnu syntax pouzitia:
lbxexec [-C] [-h [uzivatel@]host] [-a] command
kde:
-C - vyzaduje pridavnu kompresiu, vhodne na extremne pomalych linkach, inde viac na pritaz
-h - urcuje uzivatela a hosta, kde sa aplikacia spusti
-a - vykona kopirovanie .Xauthority
command je nazov aplikacie, ktora sa ma spustit
Este by sa zislo porovnat technologie VNC a LBX:
VNC-nevyhody:
- protokol moze vytvorit znacny traffic na sieti pri prilis velkej zmene obrazu
- defaultne sa nejedna o bezpecny protokol
- vytvara znacne mnozstvo trafficu aj pri akciach ako scrollovanie, kedy sa obraz posuva, nie meni
- nie je standardne dostupne, treba doinstaluvavat
VNC-vyhody:
- je mozne prevadzkovat cross-platform, ziadna zavislost na X11 / Win32 GUI, grafickych toolkitoch a pod.
LBX-nevyhody:
- pri prenose velkeho mnozstva pixmap znacne klesa jeho vykon (co je vsak eliminovane dobrou konstrukciou objektovych toolkitov v spolupraci s cache)
- dlhsi startup time, ako u VNC
- vyzaduje graficky toolkit spustanej aplikacie aj na lokalnom stroji (nie je mozne pustit GTK aplikaciu bez GTK toolkitu a pod.)
LBX-vyhody
- cacheovanie obsahu (raz zobrazena pixmapa sa viackrat po sieti neprenasa, kym sa nezmeni)
- objektovo orientovane zobrazovanie - nizky sietovy traffic pri akciach, ako scroll a pod.
- aplikacia sa chova ako lokalna, je mozne pouzivat schranku, pracovat s oknom, ako s lokalnym
- oproti VNC neprenasa srot, ako napriklad farebne prechody na tlacidlach, dekoracie menu a ine, tie obstarava lokalne graficky toolkit.
Na zaver je asi nutne dodat, ze od X11R7.1 je defaultne podpora LBX vypnuta (nekompiluje sa) a vzhladom k existencii inych vykonnejsich technologii (NX, dxpc) sa v buducnosti bude nachadzat na dropline zozname X11 servera a vytrati sa.
tazko komentovat ked prdlajs chapem vo co go :)
tak nekomentuj kdyz nevis o co go .. a taky necti takove clanky a dej se do studovani :) bude te to stat hodne probdelych noci. good luck.