Na odległość

Systemy pracy zdalnej

O zdalnej pracy mówimy wtedy, gdy np. siedząc przy swoim komputerze domowym mogę połączyć się z komputerem w firmie (albo znajdując się w Londynie połączyć się z komputerem w Krakowie...) i uruchomić na nim program, operując nim w taki sam sposób, jak gdybym pracował bezpośrednio na tamtym komputerze. Klawiatura, myszka i monitor komputera, przy którym siedzę, zachowują się wówczas jak klawiatura, myszka i monitor odległego komputera - mój komputer pełni funkcję tzw. terminala (inaczej: końcówki) komputera, z którym jestem połączony. W niniejszym tekście chciałbym przedstawić przegląd rozwiązań umożliwiających taką właśnie zdalną pracę przez sieć Internet.

Po co w ogóle zdalnie pracować na odległym komputerze? Po to, aby skorzystać z jego specyficznych zasobów - może to być moc obliczeniowa (mając np. możliwość zdalnej pracy na superkomputerze, możemy w ciągu kilku godzin wykonać obliczenia, które na PC-ecie trwałyby całymi miesiącami), określone oprogramowanie, którego nie możemy zainstalować lokalnie ze wzgędu na wymagania sprzętowe lub kwestie licencyjne, dostęp do określonych danych w sieci firmowej itp. Cokolwiek, co może nam zaoferować zdalny komputer, a czego nie ma komputer lokalny, może zadecydować o potrzebie zdalnej pracy.

"Prawdziwa" zdalna praca powinna odbywać się w trybie wielodostępnym - tzn. na jednym komputerze-serwerze może równocześnie zdalnie uruchamiać programy wielu użytkowników i nie przeszkadzają oni ani sobie nawzajem, ani ewentualnemu użytkownikowi pracującemu lokalnie, bezpośrednio przy klawiaturze danego komputera. Taki sposób pracy umożliwiają np. takie systemy operacyjne, jak Unix, OS/2 czy Windows NT; nie da się natomiast w tym sensie zdalnie pracować w systemach pozbawionych mechanizmów wielodostępu, jak DOS, Windows 95 czy Macintosh. W tych przypadkach możemy mieć do czynienia co najwyżej ze zdalnym dostępem czy "zdalnym sterowaniem" takim komputerem, które możliwe jest przy zastosowaniu programów takich jak np. pcAnywhere firmy Symantec czy Carbon Copy firmy Microcom. Oprogramowanie takie pozwala przejąć kontrolę nad komputerem, na którym uruchomiony jest taki program, z innego komputera w sieci wyposażonego w takie samo oprogramowanie, i obsługiwać go na odległość. Od "prawdziwej" zdalnej pracy sytuacja taka różni się brakiem wielodostępu: sygnały płynące z klawiatury bądź myszy komputera sterującego wywołują reakcję na ekranie komputera sterowanego (tak, jakby pochodziły od jego własnej klawiatury lub myszy), a ta z kolei wiernie przenoszona jest z powrotem na ekran pierwszego komputera. Gdyby przy sterowanym w ten sposób komputerze usiadł użytkownik, nie mógłby normalnie pracować - obaj użytkownicy (lokalny i zdalny) pracowaliby bowiem na tym samym ekranie i z tymi samymi programami, przez co przeszkadzaliby sobie nawzajem.

Oprogramowania tego typu nie omawiam w niniejszym tekście, skupiając się na usługach umożliwiających (z jednym wyjątkiem) "prawdziwą" zdalną pracę w trybie wielodostępnym. Drugą cechą charakteryzującą omówione tu rozwiązania jest fakt, że są one w dużym stopniu uniwersalne - pozwalają na komunikację między komputerami pracującymi w różnych systemach operacyjnych, podczas gdy typowe oprogramowanie do "zdalnego sterowania" wymaga korzystania z tego samego systemu na obydwu komputerach.

Dla kompletności obrazu sytuacji warto jeszcze nadmienić, że z elementami zdalnego dostępu możemy się spotkać także w przypadku programów do tzw. pracy grupowej, takich jak Microsoft Netmeeting. Dysponują one zwykle możliwością "współdzielenia" czy też "udostępniania" aplikacji działającej na komputerze jednego z uczestników telekonferencji w taki sposób, że jednocześnie mogą z niej korzystać także pozostali. Możliwość ta nie daje jednakże zdalnego dostępu do całego komputera, lecz jedynie do wybranej aplikacji, a ponadto do uaktywnienia wymaga współpracy użytkowników znajdujących się po obydwu stronach połączenia. Nie można zatem w pełni zakwalifikować jej do usług zdalnej pracy czy zdalnego dostępu, choć łączy ją z tymi usługami funkcja korzystania na odległość z programu uruchomionego na innym komputerze. Tego typu oprogramowania również nie omawiam w tym artykule.

Telnet

Czasy, w których projektowano protokół telnet, były czasem panowania wielkich komputerów, pracujących pod nadzorem wielodostępnych systemów operacyjnych, z których to komputerów korzystało się za pośrednictwem przyłączonych doń dziesiątków terminali ("prawdziwych" terminali, tzn. specjalnych monitorów z klawiaturami, podłączanych do komputera poprzez porty szeregowe - urządzenia takie można zobaczyć i dziś, np. na niektórych uczelniach, w bankach czy biurach linii lotniczych). Serwer telnetu stanowił zatem naturalne rozszerzenie tych systemów o możliwość obsługi dodatkowych, "wirtualnych" terminali, którymi stawały się małe komputery osobiste łączące się z dużą maszyną za pomocą telnetu.

Z tych "wielkich" systemów operacyjnych dziś ostał się w powszechnym użyciu właściwie jedynie Unix we wszelkich odmianach (Linux, SCO Unix, Solaris, HP-UX itd...). Każdy system unixowy standardowo zawiera serwer telnetu; dla znakomitej większości posiadaczy kont na komputerach unixowych to właśnie telnet stanowi naturalny sposób dostępu do nich. Jednak także i nowo powstające systemy operacyjne nie są pozbawione obsługi tego protokołu: można zalogować się przez telnet np. do systemu OS/2 czy Windows NT (w tym ostatnim przypadku niezbędne jest doinstalowanie serwera telnetu z pakietu NT Server Resource Kit; dostępne są również analogiczne programy niezależnych producentów). Programy klientów telnetu z kolei dostępne są w obfitości bez mała na każdy typ komputera i system operacyjny, jaki w Internecie można spotkać; tak więc bez żadnych wątpliwości możemy mówić o telnecie jako o usłudze prawdziwie uniwersalnej.

Telnet ma jednak także i wady, a właściwie jedną najpoważniejszą wadę: pracuje wyłącznie w trybie tekstowym. Nie uruchomimy za pośrednictwem telnetu na zdalnym komputerze żadnego programu działającego w trybie graficznym! Fakt ten jest często źródłem nieporozumień wśród użytkowników korzystających z klienta telnetu w środowiskach graficznych, takich jak np. Windows: skoro na lokalnym komputerze pracują w trybie graficznym, oczekują, że będzie możliwe również uruchamianie aplikacji graficznych ze zdalnego serwera. Niestety, z wykorzystaniem telnetu nie da się tego zrobić: protokół ten nie jest w żaden sposób przystosowany do przesyłania danych graficznych.

Nie w pełni nawet dostępne są możliwości trybu tekstowego - częstym problemem przy pracy przez telnet są np. kłopoty z prawidłową interpretacją niektórych klawiszy (zwłaszcza funkcyjnych albo sterujących kursorem) przez programy uruchamiane na zdalnym komputerze. Jest to następstwem "dziedzicznego obciążenia" systemów unixowych różnorodnością typów terminali, które stosowane były w dawnych komputerach. Pomiędzy terminalem a komputerem przesyłane są zasadniczo kody ASCII znaków - klawisze nie odpowiadające żadnym znakom, takie jak np. klawisze funkcyjne, muszą być kodowane w postaci specjalnych serii znaków, tzw. sekwencji sterujących. Jednakże ponieważ nie istniał jednolity standard klawiatury terminali - klawiatury poszczególnych modeli różniły się nie tylko rozkładem klawiszy, ale wręcz ich "repertuarem" (np. niektóre prymitywne terminale nie miały w ogóle klawiszy sterujących kursorem, a najpowszechniej wykorzystywany w oprogramowaniu unixowym typ terminala VT100 ma tylko cztery klawisze funkcyjne), nie istniał także zatem jednolity sposób kodowania tych klawiszy.

Unix zawiera mechanizm pozwalający programom dostosowywać się do możliwości terminala, nie wszystkie jednak programy wykorzystują go w należyty sposób, obsługując np. tylko wybrane sekwencje sterujące. Z drugiej strony - wprawdzie w programach klientów telnetu obecnie standardem są sekwencje zgodne ze wspomnianym terminalem VT100 lub jego modyfikacjami (VT102, VT220), jednak nie każdy klient w pełni realizuje wszystkie sekwencje, nie każdy też jednakowo odwzorowuje klawisze z klawiatury komputera PC na klawisze "prawdziwego" VT100. To wszystko jest powodem "terminalowego galimatiasu", objawiającego się tym, że przy pracy przez telnet z odległym systemem klawisze takie jak Page Up, Page Down czy klawisze funkcyjne nie zawsze działają tak, jak byśmy sobie tego życzyli...

Jeszcze inną wadą telnetu jest fakt, że cały przebieg sesji, włącznie z nazwą użytkownika i hasłem służącym do logowania się do systemu, transmitowany jest przez sieć otwartym tekstem. Możliwe jest zatem przechwycenie całej informacji przesyłanej podczas sesji - w szczególności hasła - przez ewentualnego hackera mającego możliwość podsłuchu (tzw. sniffingu) sieci, którą wędrują nasze dane. Ten ostatni problem rozwiązano poprzez stworzenie usługi będącej szyfrowanym odpowiednikiem telnetu - SSH (Secure Shell). Wykorzystując metodę szyfrowania z kluczem publicznym, SSH szyfruje całą sesję pomiędzy klientem a serwerem, zabezpieczając ją w ten sposób przed podsłuchem - poza tym praca przez SSH nie różni się od pracy przez telnet (więcej o SSH pisaliśmy w numerze 10/98 MI).

Usługa SSH umożliwia również tzw. tunelowanie innych połączeń sieciowych, można więc wykorzystać udostępniane przez nią zabezpieczenia także np. przy ściąganiu poczty przez POP3 (tu też wszystko jest przesyłane otwartym tekstem), albo pracy w opisywanym dalej systemie X-Window. SSH nie jest już jednak usługą tak uniwersalną jak telnet: serwer SSH dostępny jest właściwie jedynie dla systemów unixowych (powstała wprawdzie wersja dla Windows NT, ale nie jest ona jeszcze całkowicie dopracowana), zaś klient - poza Unixem - tylko dla Windows. Zarówno serwer, jak i klient dla Unixa dostępne są bezpłatnie; dla Windows początkowo istniał jedynie klient komercyjny firmy F-Secure, teraz jednakże dostępny jest także darmowy, stanowiący modyfikację popularnego windowsowego klienta telnetu - TeraTerm.

X-Window

Przy takim sposobie pracy X-serwer i X-klient mogą równie dobrze znajdować się na tym samym komputerze, co na dwóch różnych - systemowi X-Window nie robi to różnicy. Możliwe jest zatem uruchomienie programu na jednym komputerze, a wyświetlenie jego okienka i obsługiwanie go na innym. Pomiędzy komputerami unixowymi nie ma zatem żadnych problemów ze zdalną pracą w trybie graficznym - można np. zalogować się przez telnet (lub SSH) na odległą maszynę, a następnie uruchomić na niej dowolny program z poleceniem wyświetlenia okienka na naszym lokalnym komputerze. Można też, wykorzystując dostępną w systemie X-Window dodatkową usługę o nazwie XDM (X Display Manager), od razu zalogować się do zdalnego systemu w trybie graficznym.

Warto zauważyć, że w systemie X-Window pojęcia klienta i serwera są poniekąd "odwrócone" w stosunku do innych usług internetowych: komputer lokalny, przy którym bezpośrednio się znajdujemy, pełni rolę serwera, zaś aplikacje pracujące w systemie zdalnym są klientami. Wydaje się to być sprzeczne ze "zdroworozsądkowymi" skojarzeniami, które pojęcie serwera wiążą zawsze z maszyną, z którą się łączymy, ma jednak głęboki sens. Serwer dowolnej usługi sieciowej - np. telnetu, FTP czy WWW - charakteryzuje się bowiem tym, że może jednocześnie przyjmować połączenia od wielu klientów, natomiast klient zwykle jest w stanie łączyć się tylko z jednym serwerem naraz. Tak też jest i tutaj: X-serwer pracujący na naszym lokalnym komputerze może przyjmować połączenia od wielu różnych klientów-aplikacji, które mogą pracować na różnych komputerach: oznacza to, że na jednym monitorze możemy mieć wyświetlone okienka programów wykonujących się na kilku różnych komputerach i obsługiwać je wszystkie z jednego miejsca!

Choć system X-Window jest naturalnie związany z Unixem, powstały programy X-serwerów także dla innych systemów operacyjnych, jak np. DOS, Windows czy Macintosha (kilka X-serwerów dla Windows znaleźć można np. w serwisie TUCOWS: http://tucows.icm.edu.pl/, szereg firm sprzedaje też X-serwery komercyjne). Okienka aplikacji wyświetlane przez X-serwer, np. w środowisku Windows, są w pełni zintegrowane z lokalnym pulpitem (rys.1): można je zmniejszać, powiększać, zamykać czy przesuwać w ten sam sposób, jak wszystkie okienka aplikacji Windows; działa także funkcja "kopiuj i wklej" pomiędzy lokalnymi aplikacjami Windows i zdalnymi unixowymi.

Okienka aplikacji X-Window można wyświetlać na komputerach pracujących w różnych systemach operacyjnych, za to same aplikacje pracują głównie w systemach unixowych, co jest istotnym ograniczeniem uniwersalności usługi. Rzecz jasna nic nie stoi na przeszkodzie, aby napisać aplikację wykorzystującą protokół X działającą w innym systemie operacyjnym - np. w Windows; sęk jednak w tym, że o ile w Unixie wyświetlanie na ekranie lokalnym i zdalnym obsługuje się w taki sam sposób, o tyle w Windows aplikacja taka musiałaby zawierać dwa zupełnie odrębne mechanizmy wyświetlania dla obu tych przypadków. Taka komplikacja programu wydaje się zupełnie nieopłacalna w stosunku do ewentualnych korzyści, dlatego też nikt nie tworzy tego typu aplikacji. Bardziej obiecującym podejściem wydaje się próba zmodyfikowania samej warstwy graficznej systemu Windows w taki sposób, aby standardowe funkcje graficzne Windows, wywoływane przez zwykłe "windowsowe" aplikacje, były automatycznie "tłumaczone" na odpowiednie komunikaty protokołu X, wysyłane następnie do X-serwera. Tego typu rozwiązanie zastosowano np. w systemach WinCenter firmy Network Computing Devices czy WinDD firmy Tektronix, omówionych bliżej w następnym podrozdziale.

Na zakończenie warto wspomnieć, że podobnie jak w przypadku telnetu, tak i w systemie X-Window wszystkie dane przesyłane są poprzez sieć w sposób całkowicie jawny, również i tutaj istnieje zatem niebezpieczeństwo ewentualnego przechwycenia sesji. Z pomocą przychodzi wspomniana już usługa SSH: jak już opisywałem, pozwala ona na tunelowanie dowolnych połączeń sieciowych - w tym także połączeń X-Window. Gdy uruchamiamy klienta SSH w środowisku X-Window na lokalnym komputerze, opcja ta jest automatycznie uaktywniana: po nawiązaniu połączenia z komputerem zdalnym, serwer SSH na tym komputerze widoczny będzie jako dodatkowy, "wirtualny" X-serwer, z którym łączyć się będą uruchamiane aplikacje. Jedynym zadaniem, jakie wykonuje ten wirtualny X-serwer, jest przesłanie danych w zaszyfrowany sposób do lokalnego klienta SSH, który przekazuje je z kolei lokalnemu X-serwerowi do wyświetlenia. Dane wędrują zatem w postaci jawnej jedynie wewnątrz komputerów zdalnego i lokalnego; pomiędzy komputerami sesja jest zaszyfrowana.

Usługi uzupełniające

W systemach unixowych dysponujemy dodatkowymi usługami, pozwalającymi udostępnić także i te zasoby. Dyski zdalnego komputera możemy "zamontować" w naszym lokalnym drzewie katalogów za pomocą unixowej usługi NFS (Network File System) - jeżeli nie jest to możliwe, pozostaje w ostateczności "klasyczne" kopiowanie plików między lokalnym i zdalnym komputerem za pomocą FTP. Sieciowy charakter unixowego systemu drukowania pozwala nam bez problemu skierować wydruk na naszą lokalną drukarkę, o ile tylko na lokalnym komputerze działa serwer wydruku zgodny z unixowym protokołem LPD. Usługi te są standardowo dostępne w każdym systemie unixowym, oprogramowanie realizujące je można spotkać także dla systemów DOS i Windows, zwykle jako część komercyjnych pakietów oprogramowania TCP/IP dla tych systemów (np. PC-NFS firmy Sun).

Najtrudniej jest ze zdalnym odtwarzaniem dźwięku. Dostępne są wprawdzie dwie usługi umożliwiające odtwarzanie dźwięku w analogiczny sposób, jak w systemie X-Window realizowane jest wyświetlanie (tj. klient generujący dźwięk może znajdować się na jednym komputerze, zaś serwer obsługujący urządzenie odtwarzające - na innym), żadna z tych usług nie jest jednak standardowym elementem systemów unixowych i wciąż nie są one zbyt szeroko rozpowszechnione, pomimo iż istnieją już od 1994 roku. Jedną z tych usług jest opracowany przez firmę Digital system AudioFile, drugą zaś - Network Audio System (NAS), stworzony w firmie Network Computing Devices (usługę tę wykorzystuje m.in. wspomniany wyżej system WinCenter). Oprogramowanie dla obu tych usług dostępne jest na razie jedynie dla systemów unixowych.

WinFrame

WinFrame jest przerobioną przez firmę Citrix wersją systemu Windows NT Server 3.51 (Citrix kupił od Microsoftu licencję na kod źródłowy tego systemu). Przeróbka polegała przede wszystkim na wprowadzeniu do systemu możliwości wielodostępnej pracy w trybie graficznym (standardowe Windows NT dysponują pewnymi mechanizmami wielodostępu, ale ograniczonymi wyłącznie do trybu tekstowego) - technologia ta została określona przez firmę Citrix nazwą MultiWin. System WinFrame stanowi więc wielodostępny serwer, na którym można uruchamiać dowolne aplikacje działające w systemie Windows NT 3.51, korzystając z nich zdalnie za pomocą specjalnego klienta. Klient ten komunikuje się z serwerem WinFrame za pośrednictwem opracowanego przez Citrixa specjalnego protokołu o nazwie ICA (Independent Computing Architecture). W porównaniu z protokołem X, w którym przesyłana jest dość skomplikowana mieszanka tekstu ASCII, danych wektorowych i bitmap, protokół ICA jest znacznie prostszy - przesyła się tu po prostu bitmapowy obraz wirtualnego ekranu, który WinFrame udostępnia aplikacjom, a ściślej rzecz biorąc różnice między obrazem aktualnym i poprzednim. Dzięki jednak stosunkowo dobrej kompresji przesyłanych danych, efektywność wykorzystania przepustowości sieci w obu protokołach jest na zbliżonym poziomie.

Oprogramowanie klienta WinFrame dostępne było początkowo jedynie dla środowiska Windows; niedługo powstały jednak tworzone na licencji firmy Citrix przez innych producentów rozszerzenia systemu WinFrame, pozwalające wykorzystywać zamiast lub obok protokołu ICA - protokół X. Rozwiązaniami tymi były WinCenter firmy Network Computing Devices oraz WinDD firmy Tektronix. Przy zastosowaniu tego oprogramowania możliwa stała się zatem zdalna praca z aplikacjami Windows z komputerów unixowych (lub dowolnych innych, dla których dostępny był X-serwer).

Obecnie klient WinFrame oprócz Windows dostępny jest także dla DOS-a, Macintosha i systemów unixowych, stąd też powyższe rozwiązania straciły nieco na znaczeniu. Istnieje też klient WinFrame w postaci appletu Javy, możliwe jest zatem zdalne uruchamianie aplikacji Windows nawet w przeglądarce WWW (rys.2), bądź z urządzeń opartych o Javę, takich jak np. komputery sieciowe (Network Computers - NC). Aktualne wersje klientów WinFrame potrafią nie tylko przekazywać obraz zdalnej aplikacji i przesyłać informacje o wciśnięciach klawiszy i ruchach myszy, lecz także integrują w sobie obsługę dostępu do innych zasobów - np. "mapowanie" dysków lokalnego komputera do zdalnego systemu, wydruk ze zdalnej aplikacji na lokalnej drukarce czy odtwarzanie dźwięku z programu pracującego na zdalnym komputerze przez lokalną kartę dźwiękową - umożliwiając w ten sposób zdalną pracę w jak najpełniejszym znaczeniu (te dodatkowe funkcje nie są dostępne we wszystkich systemach operacyjnych). Podobnie jak w opisywanych już usługach takich jak telnet czy X-Window, także i w protokole ICA dane przesyłane są przez sieć w sposób jawny, możliwe jest jednakże dokupienie dodatkowego modułu - SecureICA - który zapewnia szyfrowanie sesji przy użyciu SSL.

Sukces WinFrame skłonił Microsoft do kupienia z kolei od Citrixa licencji na technologię MultiWin, którą firma wykorzystała do stworzenia własnej wersji wielodostępnych Windows - Windows NT 4.0 Terminal Server (możliwości Terminal Servera mają być standardowo zawarte w Windows NT 5.0, czyli Windows 2000). Licencja nie obejmuje jednak protokołu ICA - Terminal Server Microsoftu stosuje własny protokół RDP (Remote Display Protocol), którego klient dostępny jest znów tylko na platformę Windows. Ponadto w przeciwieństwie do klienta WinFrame, którego można za darmo ściągnąć z internetowej strony firmy Citrix (http://www.citrix.com/), klient Terminal Servera rozpowszechniany jest tylko wraz z samym serwerem. W podstawowej wersji Terminal Server, w przeciwieństwie do WinFrame, nie obsługuje też wprost połączeń przez Internet: przeznaczony jest raczej do użytku w obrębie sieci korporacyjnej, gdyż dla skorzystania z Terminal Servera wymagane jest standardowe zalogowanie się użytkownika do domeny Windows NT. Aby umożliwić połączenia z Internetu, niezbędne jest dokupienie dodatkowej licencji Terminal Server Internet Connector, sprzedawanej dla minimum 200 użytkowników. Terminal Server ma za to od razu wbudowaną obsługę szyfrowania sesji przez SSL.

Dla środowiska Terminal Servera firma Citrix oferuje dodatkową "nakładkę" o nazwie MetaFrame, dającą możliwość korzystania z protokołu ICA. Terminal Server uzupełniony o MetaFrame jest z grubsza funkcjonalnie identyczny z systemem WinFrame: zapewnia te same możliwości i można z niego korzystać za pomocą tych samych klientów.

VNC

Oprogramowanie, tworzone na zasadach open source (otwartego kodu) w oparciu o licencję GNU, można ściągnąć ze strony WWW o adresie http://www.uk.research.att.com/vnc/. Serwer VNC dostępny jest dla środowisk unixowych, Windows NT, a także 95 (!) oraz PowerMacintosha (nie działa na "zwykłym" Macu) - w tych systemach można uruchamiać aplikacje. Oryginalnego klienta zrealizowano dla Unixa, Windows 95/NT, Macintosha oraz - ciekawostka - dla Windows CE, czyli odmiany Windows stosowanej w komputerach kieszonkowych, a także w postaci appletu Javy. Z uwagi jednak na otwarty charakter oprogramowania, społeczność internetowa stworzyła już szereg wersji klienta VNC na inne systemy - np. Amigę, BeOS, DOS, OS/2, GEOS (system używany przez Nokia Communicator) i inne.

Zasada działania VNC opiera się na utworzeniu dla uruchamianych na serwerze aplikacji wirtualnego ekranu, którego zawartość następnie przesyłana jest przez serwer VNC do klienta. Podobnie jak w protokole ICA, także i tutaj przesyłane są jedynie różnice pomiędzy obecnym i poprzednim obrazem ekranu. Oryginalną możliwością VNC jest "zawieszanie" sesji - możemy odłączyć się od zdalnego komputera nie przerywając pracy uruchomionych aplikacji, po czym zalogować się ponownie później, nawet z innego komputera lokalnego, i wrócić do naszego ekranu wirtualnego w takim samym stanie, w jakim go pozostawiliśmy. Tak samo jak w przypadku innych omawianych w tym tekście usług, protokół stosowany w VNC transmituje dane przez sieć w postaci jawnej. Istnieje oczywiście możliwość tunelowania połączenia przez SSH, podobnie jak w przypadku X-Window; w ramach modyfikacji kodu dokonywanych przez zewnętrznych programistów powstały także wersje oprogramowania VNC obsługujące szyfrowanie połączeń protokołem SSL.

Minusem VNC jest niestety fakt, iż jedynie serwer przeznaczony dla systemów unixowych umożliwia pracę prawdziwie wielodostępną. Uruchomiony na zdalnym komputerze serwer VNC funkcjonuje z punktu widzenia działających tam aplikacji jak dodatkowy X-serwer, który nie wyświetla jednak grafiki na żadnym rzeczywistym ekranie, lecz "rysuje" ją na utworzonym w pamięci operacyjnej komputera ekranie wirtualnym. Zawartość tego ekranu przesyłana jest do klienta VNC na lokalnym komputerze i tu wyświetlana.

W przypadku serwerów dla systemów Windows 95 oraz NT, trudności techniczne związane z brakiem wielodostępu w standardowych wersjach tych systemów spowodowały, że serwer VNC dla tych systemów nie tworzy ekranów wirtualnych, lecz opiera się na rzeczywistej zawartości ekranu komputera zdalnego i przesyła do komputera lokalnego jego kopię. Analogicznie, wszelkie nasze działania klawiaturą i myszą na komputerze lokalnym znajdują swoje odbicie na rzeczywistym ekranie komputera zdalnego. VNC działa zatem w tych przypadkach analogicznie do opisanych na wstępie artykułu programów do "zdalnego sterowania" komputerem, nie zapewniając możliwości wielodostępnej zdalnej pracy (rys.3). Sytuacja zapewne ulegnie zmianie wraz z wprowadzeniem na rynek systemu Windows 2000, zawierającego technologię MultiWin Citrixa, i napisaniem serwera VNC dla tego systemu.

Poniższa tabela zawiera zestawienie najważniejszych cech opisywanych w artykule usług zdalnej pracy.

Powrót do wykazu artykułów o Internecie

Statystyka