Nigdy tak naprawdę nie rozumiałem, dlaczego system okien musi mieć serwer. Dlaczego środowiska pulpitu, menedżery wyświetlania i menedżery okien potrzebują serwera xorg? Czy to tylko mieć warstwę abstrakcji na górze karty graficznej? Dlaczego systemy okienne wykorzystują model klient-serwer? Czy komunikacja między procesami za pośrednictwem nazwanych potoków nie byłaby prostsza?
25
Odpowiedzi:
Myślę, że już zauważyłeś, że potrzebny jest jakiś „serwer”. Każdy klient (środowisko pulpitu, menedżer okien lub program okienkowy) musi współdzielić ekran ze wszystkimi pozostałymi i musi mieć możliwość wyświetlania rzeczy bez znajomości szczegółów sprzętu lub wiedzy o tym, kto jeszcze korzysta z wyświetlacza. Tak więc serwer X11 zapewnia wspomnianą warstwę abstrakcji i udostępniania, zapewniając interfejs IPC.
X11 prawdopodobnie mógłby zostać uruchomiony po nazwanych potokach, ale są dwie duże rzeczy, których nazwane potoki nie mogą zrobić.
W rzeczywistości większość klientów X rozmawia z serwerem za pomocą „nowego i ulepszonego” potoku nazwanego o nazwie gniazdo domeny UNIX. Jest bardzo podobny do potoku nazwanego, z tym wyjątkiem, że pozwala procesom mówić w obu kierunkach i śledzi, kto co powiedział. Są to te same czynności, które musi wykonywać sieć, dlatego gniazda w domenie UNIX korzystają z tego samego interfejsu programowania, co gniazda TCP / IP zapewniające komunikację sieciową.
Ale stamtąd naprawdę łatwo jest powiedzieć „Co, jeśli uruchomię serwer na innym hoście niż klient?” Wystarczy użyć gniazda TCP zamiast gniazda UNIX i voila: protokół zdalnego pulpitu, który wyprzedza Windows RDP o dekady. Mogę połączyć się
ssh
z czterema różnymi zdalnymi hostami i uruchomićsynaptic
(graficzny menedżer pakietów) na każdym z nich, a wszystkie cztery okna pojawią się na wyświetlaczu mojego komputera lokalnego.źródło
System okien nie musi mieć serwera, ale możesz zdecydować się na wdrożenie systemu okien w oparciu o model klient-serwer. Ma to kilka zalet, ponieważ wyraźnie oddzielasz działania klienta i serwera, nie muszą one działać na tym samym komputerze, a obsługa wielu klientów jest łatwiejsza. Jest to wciąż bardzo przydatne (np. Gdy
ssh
przechodzisz na inną maszynę), ale musisz zdać sobie sprawę, że w czasie, gdy X był rozwijany, było to postrzegane jako konieczność: twoja lokalna maszyna może nie być wystarczająco silna, aby uruchomić klienta.Nazwane potoki nie zapewniłyby automatycznej przewagi nad uruchomieniem przez sieć, tak jak w przypadku implementacji TCP. Ale nazwane potoki nie były np. Dostępne w DOS, z DosExtender z uruchomionym Desqview / X (1992), a AFAIK również nie w VMS. W przypadku tych implementacji problem stanowi komunikacja specyficzna dla Uniksa.
TCP nie jest specyficzny dla Uniksa i możliwe jest uruchomienie klienta w systemie VAX / VMS (rozwój X rozpoczął się w 1984 r.) I udostępnianie danych wyjściowych na lokalnej graficznej stacji roboczej z systemem UNIX. Z „X Window System: The Complete Reference to Xlib, X Protocol, ICCCM, XLFD” ¹:
Z „Podręcznika referencyjnego protokołu X” ²:
Pamiętam artykuł w TOG jako interesującą lekturę. Z pewnością wywołało to moje zainteresowanie X i (to było przed WorldWideWeb) trudnością, jaką położyłem na więcej informacji, dopóki O'Reilly nie zaczął publikować swoich książek z serii X.
¹ X Wersja 11, Wydanie 4, strona 2-X, PDF dostępny tutaj tutaj
² To jest strona 9 w drugim wydaniu, opublikowanym przez O'Reilly, które kupiłem w 1990 roku. Są nowsze wersje, ale nigdy nie zadałem sobie trudu, aby kupić te i są dostępne w AFAIK tylko w wersji papierowej. Nie sądzę, żeby zmienili uzasadnienie podziału obowiązków.
źródło
System okienkowy oznacza, że kilka niezależnych programów ma wspólny zasób, ekran i urządzenia wejściowe. Zasoby udostępnione można bezpiecznie wdrożyć tylko na dwa sposoby:
Oczywiście, dostęp do rzeczywistego sprzętu wyświetlającego jest kontrolowany przez jądro, ale nie jest to wystarczające dla systemu okienkowego: musi istnieć sposób, aby procesowi przypisano określoną część wyświetlacza (okna), w której może być w rozsądny sposób upewnij się, że żaden inny proces nie będzie zakłócał, i musi istnieć pewien poziom ochrony, która aplikacja może uzyskać dostęp do której części zasobu w danym momencie.
Teraz wszystko mogło pójść do jądra, czyli AFAIK, co robi Windows. Ma to tę zaletę, że jest szybsze (zwykle wywoływanie jądra jest znacznie szybsze niż kontaktowanie się z innym procesem), jednak ma tę wadę, że może powodować dziury w zabezpieczeniach (każde exploit systemu jest exploitem na poziomie jądra), a jednocześnie czas ogranicza możliwości przenoszenia (system zaimplementowany w jądrze jest silnie sprzężony z jądrem; nie będziesz w stanie łatwo przenieść go do innego systemu operacyjnego i całkowicie nie będziesz mógł tego zrobić, jeśli nie masz dostępu do kodu jądra).
Jeśli nie chcesz zaimplementować go w jądrze, jedynym innym sposobem na jego zaimplementowanie jest proces dedykowany, czyli serwer. Pamiętaj, że serwer, z którym nawiązano kontakt za pośrednictwem nazwanych potoków, nadal jest serwerem. Ponadto, podczas pracy na tym samym komputerze, duża część komunikacji między serwerem X a klientami odbywa się obecnie za pośrednictwem pamięci współdzielonej; to wciąż nie zmienia faktu, że serwer wyświetlania jest serwerem.
Dlaczego teraz kontaktuje się z serwerem za pomocą gniazd, a nie nazwanych potoków? Cóż, jeśli robisz to za pomocą gniazd, wystarczy mieć jedno gniazdo dla całego serwera, które może wykonać całą komunikację. Jeśli komunikujesz się z potokami, potrzebujesz dwóch potoków na klienta. Oprócz faktu, że zarządzanie wszystkimi tymi potokami byłoby dość kłopotliwe, możesz również przekroczyć pewne granice systemu operacyjnego dotyczące liczby otwartych potoków, jeśli wystarczająco wiele programów spróbuje rozmawiać z serwerem w tym samym czasie.
I oczywiście kolejną zaletą gniazd nad rurami jest to, że za pomocą gniazd można mieć połączenia między maszynami, co było szczególnie ważne w czasie, gdy rzeczywisty komputer był wspólny dla wielu osób siedzących na dedykowanych terminalach, więc programy na komputerze musiały się komunikować do różnych terminali, ale nadal jest bardzo przydatny nawet dzisiaj w środowiskach sieciowych.
źródło
X był pierwotnie opracowany i utrzymywany przez MIT. I było z licencją MIT typu open source, ale to nie ma znaczenia.
Choć postrzegany jako niekonwencjonalny, zastanów się przez chwilę; jak wytłumaczysz wybór paradygmatu klient-serwer w oprogramowaniu? I może powinienem powiedzieć prezesowi…
Oto jak nauczyłem się doceniać wybór na studiach. W kliencie-serwerze serwer zarządza zasobami, a zwłaszcza wszelkimi zasobami, które muszą być współużytkowane . Tak więc X serwer to proces, który obsługuje aplikacje klienckie , klawiaturę, mysz i bufor ramki (lub, jak piszesz na ekranie w systemie).
Chociaż nie jest to naprawdę poprawne, menedżer okien jest często wyjaśniany w następujący sposób: po prostu umieszcza uchwyty i inne dekoracje w ramce aplikacji, oknach, oknach dialogowych itp.
źródło
Modele klient-serwer to popularny projekt do wszelkiego rodzaju aplikacji, nawet gdy jest tylko jeden serwer i tylko jeden klient. Pozwalają na czysty, dobrze zdefiniowany interfejs między domenami odpowiedzialności.
Chociaż serwer i klient mogą komunikować się na wiele sposobów, wybór dokonany przez
X
(niezależnie od korzyści wymienionych przez innych) nie jest zbyteczny: możesz połączyć się zX
serwerem na innym komputerze i otworzyć okna na pulpicie (lub innym współpracującym komputerze) pulpit). Było to bardzo powszechne w czasach, gdy X był rozwijany, kiedy wiele uniwersytetów i firm posiadało serwer uniksowy i wiele „terminali X”, które z nim rozmawiały. Korzystając z gotowego do połączenia z Internetem protokołu komunikacyjnego, X można bezproblemowo używać w obrębie hostów lub między nimi.X było pierwszym środowiskiem GUI, które mogło transparentnie wyświetlać okna z innego komputera, zgodnie z historią UNIX jako środowiska dla wielu użytkowników, a nie systemu operacyjnego dla jednego użytkownika na jednym komputerze. Wiele funkcji UNIX wydaje się przesadą, jeśli jesteś jedyną osobą, która kiedykolwiek może wchodzić w interakcje (fizycznie lub zdalnie) z komputerem.
źródło
Wierzę, że x-server został zaprojektowany jako architektura klient-serwer, ponieważ początkowo zasoby komputerowe były ograniczone, a mainframe wykonały większość ciężkich zadań. Terminale X były po prostu cienkimi klientami podłączonymi do serwerów X i wyświetlającymi wszystko, co trzeba wyświetlić użytkownikowi.
Ma wiele zalet (choć protokół komunikacyjny dla X jest obecnie bardzo ciężki), w szczególności można wyświetlać ten sam ekran na wielu klientach, udostępnianie ekranu wielu użytkownikom jest w X łatwe.
źródło