X Pencere Sistemi neden bir sunucu kullanıyor?

Bir pencere sisteminin neden bir sunucuya sahip olması gerektiğini anlamadım. Masaüstü ortamları, ekran yöneticileri ve pencere yöneticileri neden xorg-server'a ihtiyaç duyuyor? Grafik kartının üstüne yalnızca bir soyutlama katmanı mı var? Pencere sistemleri neden bir istemci-sunucu modeli kullanıyor? İsimlendirilmiş borular aracılığıyla süreçler arası iletişim daha kolay olmaz mıydı?

Bir çeşit "sunucu" gerektiğinin farkına vardığınızı düşünüyorum. Her müşterinin (masaüstü ortamı, pencere yöneticisi veya pencereli program) ekranı diğerleriyle paylaşması gerekir ve donanımın ayrıntılarını bilmeden ya da ekranı kimin kullandığını bilmeden bir şeyleri gösterebilmeleri gerekir. Böylece, X11 sunucusu bir IPC arayüzü sağlayarak bahsettiğiniz soyutlama ve paylaşım katmanını sağlar.

X11 muhtemelen adlandırılmış yöneltmeler üzerinden koşmak için yapılmış olabilir, fakat yöneltmelerin yapamayacağı iki büyük şey var.

• Adlandırılmış borular yalnızca bir yönde iletişim kurar.
• İki işlem, verileri adlandırılmış bir borunun "gönderme" sonuna koymaya başlarsa, veriler birbirine karışır.

Aslında, çoğu X istemcisi, UNIX alan adı soketi adı verilen "yeni ve geliştirilmiş" bir kanal kullanarak sunucuyla konuşur. İşlemlerin her iki yönde de konuşmasına izin vermesi haricinde, adlandırılmış bir boruya çok benziyor ve kimin ne dediğini takip ediyor. Bunlar, ağın yapması gerekenlerle aynıdır ve bu nedenle UNIX etki alanı soketleri, ağ iletişimi sağlayan TCP / IP soketleri ile aynı programlama arabirimini kullanır.

Ancak oradan, "Sunucuyu istemciden farklı bir ana bilgisayara koyarsam ne olur?" Demek gerçekten kolaydır. Sadece UNIX soketi yerine bir TCP soketi ve voila kullanın: Windows RDP'yi on yıllarca önleyen uzak masaüstü protokolü. Elimden sshdört farklı uzaktaki bilgisayar ve çalışma için synapticbunların her biri üzerinde (grafik paket yöneticisi) ve dört pencere benim yerel bilgisayarın ekranda görünür.

Bir pencere sisteminin bir sunucusu olması gerekmez, ancak bir istemci-sunucu modeline dayalı bir pencere sistemi uygulamaya karar verebilirsiniz. Bunu yapmak, istemcideki ve sunucudaki etkinlikleri açıkça ayırdığınız için birkaç avantaja sahiptir, aynı makinede çalıştırmaları gerekmez ve birden çok müşteriye hizmet vermek daha kolaydır. Bu şu anda hala çok kullanışlıdır (örneğin sshbaşka bir makineye girdiğinizde), ancak X'in geliştirildiği sırada, bunun bir zorunluluk olarak görüldüğünü anlamalısınız: yerel makineniz müşteriyi çalıştıracak kadar güçlü olmayabilir.

Adlandırılmış kanallar, bir TCP uygulamasının yapacağı gibi ağ üzerinden çalışabilmenin otomatik avantajını sağlamaz. Ancak, adlandırılmış yöneltmeler örneğin DOS üzerinde mevcut değildi, DosExtender Desqview / X (1992) kullanıyordu ve AFAIK de VMS'de yoktu. Bu uygulamalar için bir Unix'e özgü iletişim sorun olacaktır.

TCP, Unix'e özgü değildir ve VAX / VMS (X geliştirme 1984'te başladı) altında çalışan ve yerel UNIX tabanlı grafik iş istasyonunuza çıktı sunan bir müşteriye sahip olmak mümkündür. "X Pencere Sistemi: Xlib, X Protokolü, ICCCM, XLFD" ye Tam Referans "¹:

1986'nın sonbaharında Digital, ULTRIX, VMS ve MS-DOS için tüm masaüstü iş istasyonu stratejisini X'e dayandırmaya karar verdi. Bu biraz gecikmeyle sonuçlandı, fakat sonuçta daha iyi bir tasarımla sonuçlandı. Ralph Swick, bu dönemde Project Athena'ya katıldı ve 11. versiyonun gelişimi boyunca hayati bir rol oynadı. Son 10 sürüm, Aralık 1986'da yayınlandı.

"X Protokol Referans El Kitabı" ²'den:

Sorumlulukların dağılımı

X protokolünü tasarlama sürecinde, sunucu ile müşteri arasındaki kabiliyet bölünmesine çok fazla düşünülen düşünce, istek, cevap ve olaylarla hangi bilgilerin ileri geri iletilmesi gerektiğini belirler. Protokolün tasarlanmasında yapılan bazı seçimlerin ardındaki mantık hakkında mükemmel bir bilgi kaynağı, X Computer System adlı makalede, Robert W. Scheifler ve Jim Gettys tarafından yazılmıştır. 2, Nisan 1986 Nihai kararlar, müşteri programlarının taşınabilirliğine, müşteri programlamanın kolaylığına ve performansına dayanıyordu.

İlk olarak, sunucu, temel donanımdaki farklılıkları istemci uygulamalarından gizlemek için mümkün olduğunca tasarlanmıştır. ...

TOG’daki makalenin ilginç bir okuma olduğunu hatırlıyorum. Kesinlikle X'e olan ilgimi tetikledi ve (bu WorldWideWeb'den önceydi) O'Reilly X serisi kitaplarını yayınlamaya başlayana kadar ellerimi daha fazla bilgi üzerine koymamdaki güçlüğü.

¹ _{X Sürüm 11, Sürüm 4, sayfa 2-X, PDF çevrimiçi olarak buradan edinilebilir}
² _{Bu, 1990'da satın aldığım O'Reilly tarafından yayınlanan 2. basımın 9. sayfasında. Daha yeni basımlar var, bunlar ve bunlar AFAIK'tir, sadece kağıtta da mevcuttur. Sorumlulukların ayrılmasının gerekçesini değiştirdiklerini sanmıyorum.}

Pencereleme sistemi, birçok bağımsız programın ortak bir kaynağı, ekranı ve giriş cihazlarını paylaştığı anlamına gelir. Paylaşılan kaynaklar yalnızca iki şekilde güvenle uygulanabilir:

• Kaynak, çekirdek tarafından kontrol edilebilir ve uygulamalar ona erişmek için çekirdek çağrıları yapar.
• Kaynak özel bir işlem (sunucu) tarafından kontrol edilebilir ve uygulamalar erişmek için sunucuya başvurur.

Elbette, asıl ekran donanımına erişim çekirdek tarafından kontrol edilir, ancak bu bir pencere sistemi için yeterli değildir: Bir işlemin ekranın belirli bir bölümüne (pencere) makul bir şekilde atanabileceği bir yol olmalıdır. Başka hiçbir sürecin müdahale etmeyeceğinden ve hangi zamanda kaynak kaynağının hangi kısmına erişebileceği konusunda belirli bir koruma seviyesi olması gerektiğinden emin olun.

Şimdi her şey çekirdeğe girebilirdi, bu da AFAIK’in Windows’un yaptığı gibi. Bunun daha hızlı olma avantajı vardır (genellikle çekirdeğin başka bir işlemle iletişim kurmaktan çok daha hızlı olması), ancak muhtemelen güvenlik delikleri açmanın dezavantajı vardır (sistemin herhangi bir şekilde kullanılması, çekirdek düzeyinde bir istismardır) ve aynı şekilde zaman taşınabilirliği sınırlar (çekirdeğe uygulanan bir sistem çekirdeğe güçlü bir şekilde bağlanır; onu başka bir işletim sistemine kolayca bağlayamazsınız ve çekirdek koduna erişiminiz yoksa bunu yapamazsınız).

Çekirdeğe uygulamak istemiyorsanız, uygulamanın tek yolu özel bir işlem, yani bir sunucudur. Adlandırılmış yöneltmeler aracılığıyla iletişim kurulmuş bir sunucunun hala bir sunucu olduğunu unutmayın. Ayrıca, aynı makinede çalışırken, X sunucusu ile istemciler arasındaki iletişimin büyük kısmı bugünlerde paylaşılan bellekle oluyor; Bu hala ekran sunucusunun bir sunucu olduğu gerçeğini değiştirmiyor.

Şimdi, sunucuya neden soketlerle temas ediliyor ve adlandırılmış yöneltmeler kullanmıyor? Peki, soket kullanarak yaparsanız, tüm iletişimi yapabilen tüm sunucu için bir sokete ihtiyacınız olacaktır. Borularla iletişim kurarsanız, müşteri başına iki boruya ihtiyacınız vardır. Tüm bu boruları yönetmek oldukça zahmetli olmasının yanı sıra, yeterince sayıda program aynı anda sunucuyla konuşmaya çalışırsa, açık sistemlerin kullanımında bazı işletim sistemi sınırlarını aşabilirsiniz.

Ve tabii ki borular üzerindeki soketlerin başka bir avantajı, soketlerle, makineler arasında bağlantı kurabileceğiniz ve özellikle gerçek bilgisayarın özel terminallerde oturan birçok kişi tarafından paylaşıldığı bir zamanda önemli olduğu, bu yüzden bilgisayardaki programların iletişim kurması gerektiğidir. Farklı terminallere, ancak bugün bile ağ ortamında bile çok faydalıdır.

X aslında MIT tarafından geliştirildi ve sürdürüldü. Açık kaynak kodlu bir MIT lisansına sahipti, öyle değil, bu gerçekten önemli.

Alışılmamış olarak görülmesine rağmen, bir an için düşünün; Bir istemci-sunucu paradigmasını bir yazılımda kullanma tercihini nasıl açıklarsınız? Ve belki de bir CEO'ya söylemeliyim ..

İşte üniversitedeki seçimi takdir etmeyi öğrendim. İstemci-sunucuda, sunucu kaynakları ve özellikle de paylaşılması gereken kaynakları yönetir . Bu nedenle, X sunucusu, istemci uygulamalarına, klavyeye, fareye ve çerçeveye ayırıcıya (veya sisteminizdeki ekrana yazıyorsunuz) hizmet veren bir işlemdir .

Gerçekten doğru olmamakla birlikte, pencere yöneticisi genellikle şöyle açıklanır: Basitçe, uygulamanın çerçevesine tutamaçları ve diğer süsleri, pencereleri, diyalogları vb.

İstemci-sunucu modelleri, yalnızca bir sunucu ve bir istemci olsa bile, her türlü uygulama için popüler bir tasarımdır. Sorumluluk alanları arasında temiz ve iyi tanımlanmış bir arayüz sağlarlar.

Bir sunucu ve istemci iletişim kuramadı birçok yolu olsa da, seçim tarafından yapılan X(bakılmaksızın başkaları tarafından bahsedilen avantajları) gereksiz değildir: Sen edebilirsiniz bir bağlanmaya Xbaşka işbirliği masaüstünüzde farklı bir makinede ve açık pencerelerde sunucusu (veya üzerinde masaüstü). Bu, X'in geliştirildiği günlerde, birçok Üniversite ve işletmenin bir Unix sunucusuna ve onunla konuşan birçok "X terminaline" sahip olacağı zaman çok yaygındı. İnternete hazır bir iletişim protokolü kullanarak, X ana bilgisayarların içinde veya arasında sorunsuz şekilde kullanılabilir.

X, tek bir bilgisayardaki tek bir kullanıcı için bir işletim sistemi yerine, UNIX'in çok kullanıcılı bir ortam olarak geçmişiyle tutarlı bir şekilde pencereleri başka bir makineden şeffaf bir şekilde görüntüleyebilen ilk GUI ortamıydı. Bilgisayarınızla (fiziksel olarak veya uzaktan) etkileşime girebilecek tek kişi sizseniz, birçok UNIX özelliği fazladan görünebilir.

X-server'ın istemci-sunucu mimarisi olarak tasarlandığına inanıyorum, çünkü başlangıçta hesaplama kaynakları azdı ve ana bilgisayarlar ağır yüklerin çoğunu yaptı. X-terminalleri, x-sunucularına bağlanan ve kullanıcıya gösterilmesi gerekenleri görüntüleyen ince istemcilerdi.

Günümüzde X'in iletişim protokolü olsa da, çok fazla faydası var, özellikle aynı ekranı birden fazla müşteride görüntüleyebilir, bir ekranı birden fazla kullanıcıyla paylaşmak X'te kolaydır.