Dlaczego system X Window korzysta z serwera?

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?

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ć.

• Nazwane potoki komunikują się tylko w jednym kierunku.
• Jeśli dwa procesy zaczną umieszczać dane na końcu „wysyłania” nazwanego potoku, dane zostaną zmieszane.

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ę sshz 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.

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 sshprzechodzisz 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” ¹:

Jesienią 1986 roku firma Digital postanowiła oprzeć całą swoją strategię stacji roboczych ULTRIX, VMS i MS-DOS na X. Chociaż było to dla nas satysfakcjonujące, oznaczało to, że mieliśmy jeszcze więcej osób do rozmowy. Spowodowało to pewne opóźnienie, ale ostatecznie przyniosło także lepszy projekt. Ralph Swick of Digital dołączył do Project Athena w tym okresie i odegrał istotną rolę w rozwoju wersji 11. Ostatnia wersja 10 została udostępniona w grudniu 1986 roku.

Z „Podręcznika referencyjnego protokołu X” ²:

Podział obowiązków

Podczas projektowania protokołu X wiele przemyślenia poświęcono podziałowi możliwości między serwerem a klientem, ponieważ określa to, jakie informacje należy przekazywać tam iz powrotem za pośrednictwem żądań, odpowiedzi i zdarzeń. Doskonałym źródłem informacji o uzasadnieniu niektórych wyborów dokonanych przy projektowaniu protokołu jest artykuł The X Window System autorstwa Roberta W. Scheiflera i Jima Gettysa opublikowany w czasopiśmie Association of Computing Machinery Transaction on Graphics, Vol. 5, No. 2 kwietnia 1986 Ostatecznie podjęte decyzje były oparte na przenośności programów klienckich, łatwości programowania klienckiego i wydajności.

Po pierwsze, serwer jest tak zaprojektowany, jak to tylko możliwe, aby ukryć różnice w sprzęcie bazowym przed aplikacjami klienckimi. ...

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.}

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:

• Zasób może być kontrolowany przez jądro, a aplikacje wykonują wywołania jądra, aby uzyskać do niego dostęp.
• Zasób może być kontrolowany przez dedykowany proces (serwer), a aplikacje kontaktują się z serwerem, aby uzyskać do niego dostęp.

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.

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.

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ę z Xserwerem 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.

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.