एक्स विंडो सिस्टम एक सर्वर का उपयोग क्यों करता है?

25

मैं वास्तव में कभी नहीं समझ पाया कि विंडो सिस्टम में सर्वर क्यों होना चाहिए। डेस्कटॉप वातावरण, डिस्प्ले मैनेजर और विंडो मैनेजर को xorg- सर्वर की आवश्यकता क्यों है? यह केवल ग्राफिक्स कार्ड के शीर्ष पर अमूर्त की एक परत है? विंडो सिस्टम क्लाइंट-सर्वर मॉडल को क्यों नियोजित करते हैं? नामित पाइप के माध्यम से अंतर-प्रक्रिया संचार सरल नहीं होगा?

xorg x11 x-server

— आदित एम शाह
स्रोत

2

नामांकित पाइप सरल नहीं होंगे क्योंकि पाइप केवल एक तरह से संचार के लिए हैं। यदि आप दो तरह से संचार चाहते हैं तो आप पाइप के बजाय सॉकेट का उपयोग करते हैं। और वास्तव में कुछ नए सिस्टम टीसीपी सॉकेट के बजाय डिफ़ॉल्ट रूप से नामित (यूनिक्स डोमेन) सॉकेट का उपयोग करते हैं। उदाहरण के लिए Ubuntu 14.04 पर, X डिफ़ॉल्ट रूप से एक टीसीपी सॉकेट पर न सुनने के लिए कॉन्फ़िगर किया गया है।

— 23

5

पीसी से पहले यूनिक्स और एक्स का विकास इतना शक्तिशाली और सस्ता हो गया था, जहां एक आम तौर पर आपके पास एक या कुछ अधिक शक्तिशाली कंप्यूटरों से जुड़े बहुत सारे सरल टर्मिनल थे। यह विभाजन एक्स के साथ किया गया था: आपके पास "टर्मिनल" थे - ग्राफिक्स-कार्ड के साथ सरल सस्ते कंप्यूटर - बस एक्स-सर्वर चलाने, और माउस / कीबोर्ड से इनपुट इकट्ठा करना और स्क्रीन को आकर्षित करना ... वास्तविक कार्यक्रम (एक्स-) ग्राहकों) दूसरी ओर, एक या कुछ अधिक शक्तिशाली कंप्यूटरों पर भाग गया - सभी उपयोगकर्ताओं द्वारा टर्मिनलों का उपयोग करके साझा किया गया। इसलिए एक्स को दो भागों में विभाजित करना (जो अलग हो सकता है), समझ में आया।

— बार्ड कोपरपुड

@BaardKopperud X विंडो के लोकप्रिय होने के वर्षों बाद X टर्मिनल आए, इसलिए वे इस कारण नहीं हो सके कि X विंडो को इस तरह से आर्किटेक्चर किया गया था। एक्स ने यूनिक्स वर्कस्टेशन के साथ शुरू किया जो एक्स सर्वर से अधिक चल रहा था।

— jlliagre

39

मुझे लगता है कि आपने पहले ही ध्यान दिया है कि किसी प्रकार के "सर्वर" की आवश्यकता है। प्रत्येक क्लाइंट (डेस्कटॉप वातावरण, विंडो मैनेजर, या विंडो प्रोग्राम) को अन्य सभी के साथ डिस्प्ले साझा करने की आवश्यकता होती है, और उन्हें हार्डवेयर के विवरण को जानने के बिना चीजों को प्रदर्शित करने में सक्षम होना चाहिए, या यह जानना चाहिए कि डिस्प्ले का उपयोग कौन कर रहा है। तो X11 सर्वर IPC इंटरफ़ेस प्रदान करके अमूर्त और साझा करने की परत प्रदान करता है।

X11 को संभवतया नामित पाइपों पर चलाने के लिए बनाया जा सकता है, लेकिन एक दो बड़ी चीजें हैं जिनका नाम पाइप नहीं कर सकते हैं।

नामित पाइप केवल एक दिशा में संचार करते हैं।
यदि दो प्रक्रियाएं एक नामित पाइप के "भेजने" के अंत में डेटा डालना शुरू करती हैं, तो डेटा परस्पर मिल जाएगा।

वास्तव में, अधिकांश एक्स क्लाइंट यूनिक्स-डोमेन सॉकेट नामक "नए और बेहतर" पाइप का उपयोग करके सर्वर से बात करते हैं। यह नामांकित पाइप की तरह बहुत है, सिवाय इसके कि दोनों दिशाओं में प्रक्रियाओं को बात करने देता है, और यह ट्रैक रखता है कि किसने क्या कहा। ये उसी तरह की चीजें हैं जो नेटवर्क को करना है, और इसलिए UNIX- डोमेन सॉकेट्स टीसीपी / आईपी सॉकेट्स के समान प्रोग्रामिंग इंटरफ़ेस का उपयोग करते हैं जो नेटवर्क संचार प्रदान करते हैं।

लेकिन वहां से, यह कहना आसान है कि "क्या होगा अगर मैं क्लाइंट से अलग होस्ट पर सर्वर चलाता हूं?" बस यूनिक्स सॉकेट के बजाय एक टीसीपी सॉकेट का उपयोग करें, और वॉइला: एक दूरस्थ-डेस्कटॉप प्रोटोकॉल जो दशकों से विंडोज आरडीपी से पहले होता है। मैं sshचार अलग-अलग रिमोट होस्ट कर सकता हूं और synapticउनमें से प्रत्येक पर (ग्राफिकल पैकेज मैनेजर) चला सकता हूं, और मेरे स्थानीय कंप्यूटर के प्रदर्शन पर सभी चार खिड़कियां दिखाई देती हैं।

— Jander
स्रोत

2

X ने SysV सिस्टम पर नामित पाइप का इस्तेमाल किया जहां नाम वाले पाइप द्वि-दिशात्मक थे, जिनमें Solaris और SCO Unixes शामिल थे।

— alanc

14

एक विंडो सिस्टम में सर्वर नहीं होता है, लेकिन आप क्लाइंट-सर्वर मॉडल के आधार पर विंडो सिस्टम को लागू करने का निर्णय ले सकते हैं। ऐसा करने के कई फायदे हैं क्योंकि आप क्लाइंट और सर्वर में गतिविधियों को स्पष्ट रूप से अलग करते हैं, उन्हें एक ही मशीन पर चलने की आवश्यकता नहीं है और कई क्लाइंट्स को सेवा देना अधिक आसान है। यह वर्तमान में बहुत उपयोगी है (उदाहरण के लिए जब आप sshकिसी अन्य मशीन में), लेकिन आपको यह महसूस करना होगा कि जिस समय एक्स विकसित हुआ था, उस समय इसे एक आवश्यकता के रूप में देखा गया था: आपका स्थानीय मशीन क्लाइंट को चलाने के लिए पर्याप्त शक्तिशाली नहीं हो सकता है।

नामांकित पाइप आपको टीसीपी कार्यान्वयन के रूप में नेटवर्क पर चलने में सक्षम होने का स्वत: लाभ नहीं देंगे। लेकिन नामित पाइप उदाहरण के लिए DOS पर उपलब्ध नहीं थे, DosExtender में Desqview / X (1992) चल रहा था, और AFAIK भी VMS पर नहीं थे। उन कार्यान्वयनों के लिए एक यूनिक्स विशिष्ट संचार एक समस्या होगी।

टीसीपी यूनिक्स विशिष्ट नहीं है और यह संभव है कि क्लाइंट के पास वैक्स / वीएमएस (1984 में शुरू किया गया एक्स विकास) हो और अपने स्थानीय यूनिक्स आधारित ग्राफिक्स वर्कस्टेशन को आउटपुट प्रदान करना। "एक्स विंडो सिस्टम: एक्सलिब, एक्स प्रोटोकॉल, आईसीसीसीएम, एक्सएलएफडी" का पूरा संदर्भ: System:

1986 के पतन के दौरान, डिजिटल ने ULTRIX, VMS और MS-DOS के लिए X पर अपनी पूरी डेस्कटॉप वर्कस्टेशन रणनीति को आधार बनाने का फैसला किया। हालांकि यह हमारे लिए संतुष्टिदायक था, लेकिन इसका मतलब यह भी था कि हमारे पास और भी लोग हैं जिनसे बात करनी थी। इसके परिणामस्वरूप कुछ देरी हुई, लेकिन, अंत में, यह एक बेहतर डिजाइन भी हुआ। इस अवधि में डिजिटल के राल्फ स्विक प्रोजेक्ट एथेना में शामिल हो गए और संस्करण 11 के विकास में महत्वपूर्ण भूमिका निभाई। अंतिम क्रिया-सायन 10 रिलीज़ दिसंबर 1986 में उपलब्ध कराया गया था।

"एक्स प्रोटोकॉल संदर्भ मैनुअल" से:

जिम्मेदारियों का विभाजन

एक्स प्रोटोकॉल को डिजाइन करने की प्रक्रिया में, बहुत सोचा सर्वर और क्लाइंट के बीच क्षमता के विभाजन में चला गया, यह निर्धारित करता है कि अनुरोधों, उत्तरों और घटनाओं के माध्यम से क्या जानकारी आगे और पीछे पारित की जानी है। प्रोटोकॉल को डिजाइन करने में किए गए कुछ विकल्पों के पीछे तर्क के बारे में जानकारी का एक उत्कृष्ट स्रोत लेख है एक्स विंडो सिस्टम, रॉबर्ट डब्ल्यू। Scheifler और जिम गेट्टी द्वारा, ग्राफिक्स, वॉल्यूम 5, नंबर 5 पर एसोसिएशन ऑफ कंप्यूटिंग मशीनरी पत्रिका में प्रकाशित। 2, अप्रैल 1986 निर्णय अंततः ग्राहक कार्यक्रमों की पोर्टेबिलिटी, क्लाइंट प्रोग्रामिंग में आसानी और प्रदर्शन पर आधारित थे।

सबसे पहले, सर्वर को डिज़ाइन किया गया है, जितना संभव हो, क्लाइंट अनुप्रयोगों से अंतर्निहित हार्डवेयर में अंतर छिपाने के लिए। ...

मुझे याद है कि टीओजी में लेख एक दिलचस्प पढ़ा जा रहा है। इसने निश्चित रूप से एक्स में मेरी दिलचस्पी पैदा कर दी और (यह वर्ल्डवाइडवेब से पहले था) जब तक ओ'रेली ने अपनी श्रृंखला एक्स किताबें प्रकाशित करना शुरू नहीं किया था, तब तक हम और अधिक जानकारी पर अपने हाथ रख रहे थे।

¹ _{एक्स संस्करण 11, रिलीज 4, पेज 2 एक्स, पीडीएफ उपलब्ध ऑनलाइन यहाँ}
² _{यह 2 संस्करण, ओ रेली द्वारा प्रकाशित में पेज 9 से है, कि मैं 1990 में खरीदा नए संस्करणों को कर रहे हैं, लेकिन मैं कभी नहीं खरीद करने के लिए परेशान ये और वे AFAIK केवल कागज में भी उपलब्ध हैं। मुझे नहीं लगता कि उन्होंने जिम्मेदारियों के विभाजन के औचित्य को बदल दिया है।}

— Anthon
स्रोत

2

हमने समर्पित एक्स टर्मिनलों का भी उपयोग किया, जो डिस्क रहित, निष्क्रिय रूप से ठंडा और तुरंत बदली जाने योग्य थे, जिनमें से सभी 100 सीटों की आवश्यकता होने पर महान हैं।

— साइमन रिक्टर

7

एक विंडोिंग सिस्टम का अर्थ है कि कई स्वतंत्र प्रोग्राम एक साझा संसाधन, स्क्रीन और इनपुट डिवाइस साझा करते हैं। साझा संसाधन केवल दो तरीकों से सुरक्षित रूप से लागू किए जा सकते हैं:

संसाधन को कर्नेल द्वारा नियंत्रित किया जा सकता है, और अनुप्रयोग इसे एक्सेस करने के लिए कर्नेल कॉल करते हैं।
संसाधन को एक समर्पित प्रक्रिया (सर्वर) द्वारा नियंत्रित किया जा सकता है, और अनुप्रयोग इसे एक्सेस करने के लिए सर्वर से संपर्क करते हैं।

बेशक, वास्तविक प्रदर्शन हार्डवेयर तक पहुंच कर्नेल द्वारा नियंत्रित की जाती है, लेकिन यह एक विंडोिंग सिस्टम के लिए पर्याप्त नहीं है: प्रक्रिया का एक तरीका असाइन किया जाना चाहिए ताकि डिस्प्ले (विंडो) का एक निश्चित भाग सौंपा जा सके जहां यह यथोचित हो सकता है सुनिश्चित करें कि कोई अन्य प्रक्रिया हस्तक्षेप नहीं करेगी, और इस बात की सुरक्षा का एक निश्चित स्तर होना चाहिए कि कौन सा अनुप्रयोग किस समय तक पुन: स्रोत के किस हिस्से तक पहुंच सकता है।

अब पूरी बात कर्नेल में जा सकती थी, जो कि AFAIK है जो विंडोज करता है। इससे तेज़ होने का फायदा होता है (आमतौर पर कर्नेल को कॉल करना किसी अन्य प्रक्रिया से संपर्क करने की तुलना में बहुत तेज़ होता है), हालांकि इससे संभवतः सुरक्षा छिद्रों को खोलने का नुकसान होता है (सिस्टम का कोई भी शोषण कर्नेल स्तर पर एक शोषण है), और उसी पर समय पोर्टेबिलिटी को प्रतिबंधित करता है (कर्नेल में लागू एक सिस्टम कर्नेल के साथ दृढ़ता से युग्मित होता है; आप इसे आसानी से किसी अन्य ऑपरेटिंग सिस्टम पर पोर्ट नहीं कर पाएंगे, और यदि आप कर्नेल कोड तक पहुंच नहीं पाते हैं तो पूरी तरह से असमर्थ हैं)।

यदि आप इसे कर्नेल में लागू नहीं करना चाहते हैं, तो इसे लागू करने का एकमात्र तरीका एक समर्पित प्रक्रिया के रूप में है, अर्थात, एक सर्वर। ध्यान दें कि नामित पाइप के माध्यम से संपर्क किया जाने वाला सर्वर अभी भी एक सर्वर है। इसके अलावा, जब एक ही मशीन पर चल रहा हो, तो इन दिनों साझा मेमोरी के माध्यम से एक्स सर्वर और क्लाइंट के बीच बहुत अधिक संचार होता है; यह अभी भी इस तथ्य को नहीं बदलता है कि प्रदर्शन सर्वर एक सर्वर है।

अब, सर्वर को सॉकेट्स का उपयोग करके संपर्क क्यों किया जाता है, और नामित पाइपों का उपयोग नहीं किया जाता है? ठीक है, यदि आप सॉकेट्स का उपयोग करते हैं, तो आपको पूरे सर्वर के लिए एक सॉकेट होना चाहिए, जो सभी संचार कर सकते हैं। यदि आप पाइप के साथ संवाद करते हैं, तो आपको प्रति ग्राहक दो पाइप चाहिए। इस तथ्य के अलावा कि उन सभी पाइपों का प्रबंधन काफी बोझिल होगा, आप खुले पाइपों की संख्या पर कुछ ऑपरेटिंग सिस्टम की सीमाएं भी मार सकते हैं यदि पर्याप्त रूप से कई प्रोग्राम एक ही समय में सर्वर से बात करने की कोशिश करते हैं।

और निश्चित रूप से पाइपों पर सॉकेट्स का एक और फायदा यह है कि सॉकेट्स के साथ आपके पास मशीनों में कनेक्शन हो सकते हैं, जो विशेष रूप से उस समय महत्वपूर्ण था, जहां वास्तविक कंप्यूटर को समर्पित टर्मिनलों पर बैठे कई लोगों द्वारा साझा किया गया था, इसलिए कंप्यूटर पर प्रोग्राम को संवाद करना था विभिन्न टर्मिनलों के लिए, लेकिन यह अभी भी बहुत ही उपयोगी है आज भी नेटवर्क वाले वातावरण में।

— celtschk
स्रोत

आपकी एमएस विंडोज धारणा आंशिक रूप से सही है - विंडोिंग सिस्टम के लिए आवश्यक संरचना में से कुछ सॉर्ट- इन-कर्नेल है - लेकिन यह जटिल है। विंडोज के बारे में आपको आश्चर्य हो सकता है कि हम इसके साथ जो कुछ जोड़ते हैं, वह वास्तव में एकल उपयोगकर्ता-मोड सबसिस्टम के लिए विशिष्ट है - Win32 सबसिस्टम - एक vm जैसा कुछ। कर्नेल खुद - और उसके घटक कार्यकारी मॉड्यूल - उस सब से अलग बैठते हैं। यह वह पृथक्करण है जो NT कर्नेल को संचालित करने के लिए एक अलग POSIX सबसिस्टम की अनुमति देता है। इसे बाहर की जाँच करें

— mikeserv

1

जब मैं वास्तव में उस विशिष्ट डिज़ाइन के बारे में नहीं जानता था, तो लिंक किए गए लेख में छवि को देखते हुए, मैं कर्नेल स्थान में एक बॉक्स देखता हूं जिसमें "विंडो मैनेजर" शब्द होता है। चूंकि वास्तविक विंडो सजावट व्यक्तिगत कार्यक्रमों द्वारा तैयार की जाती है (इसलिए इसमें X11 विंडो प्रबंधक जैसा कुछ भी नहीं है), मैं केवल यह निष्कर्ष निकाल सकता हूं कि यह घटक है जो मूल रूप से एक ही काम करता है जो कि X11 डिस्प्ले सर्वर करता है। Win32 भागों की संभावना X11 विंडो प्रबंधकों (जो कि X11 सर्वर का हिस्सा नहीं है!) और X11 टूलकिट्स (एक्स में क्लाइंट के संदर्भ में भी) की कार्यक्षमता का एक संयोजन है ।

— celtschk

हाँ - यह है कि मैं क्या तरह से / कुछ का मतलब है - कि कार्यकारी सेवा की परत है - यह उन सेवाओं के एक हॉज की तरह है जो कर्नेल मोड में चलती हैं, लेकिन अपने आप में और अलग मॉड्यूल हैं। मुझे लगता है कि कर्नेल है - उसी तरह लिनक्स कर्नेल ड्राइवरों को संकलित करने की आवश्यकता नहीं है, लेकिन इसे लोड / अनलोड किया जा सकता है। यह सिर्फ विंडोज के साथ अजीब है क्योंकि यह सब लपेटता है। वैसे भी, मैंने हमेशा सोचा है कि यह दिलचस्प था - लेकिन मैं कोई विशेषज्ञ नहीं हूं । आपके जवाब ने मुझे इसकी याद दिला दी।

— mikeserv

2

X मूल रूप से, MIT द्वारा विकसित और अनुरक्षित था, यह एक ओपन सोर्स MIT लाइसेंस के साथ था, न कि, जो वास्तव में मायने रखता है।

जबकि अविवेकी के रूप में देखा जाता है, एक पल के लिए विचार करें; आप सॉफ्टवेयर के एक टुकड़े में एक क्लाइंट-सर्वर प्रतिमान का उपयोग करने के लिए एक विकल्प की व्याख्या कैसे करेंगे? और, शायद मुझे एक सीईओ से कहना चाहिए ।।

यहाँ बताया गया है कि कैसे मैंने कॉलेज में चुनाव की सराहना की। क्लाइंट-सर्वर में, सर्वर संसाधनों का प्रबंधन करता है, और विशेष रूप से , किसी भी संसाधन को साझा किया जाना चाहिए । तो, एक्स सर्वर वह प्रक्रिया है जो क्लाइंट ऐप्स, कीबोर्ड, माउस, और फ्रेमबफ़र (या, हालांकि आप अपने सिस्टम पर स्क्रीन पर लिखते हैं) के लिए कार्य करते हैं।

वास्तव में सही नहीं होने पर, विंडो मैनेजर को अक्सर इस तरह से समझाया जाता है: यह बस है, यह बात है, कि एक ऐप के फ्रेम पर हैंडल और अन्य सजावट, और खिड़कियां, संवाद आदि।

— दान लाबेल
स्रोत

0

क्लाइंट-सर्वर मॉडल सभी प्रकार के अनुप्रयोगों के लिए एक लोकप्रिय डिज़ाइन हैं, तब भी जब केवल एक सर्वर और केवल एक क्लाइंट होता है। वे जिम्मेदारी के डोमेन के बीच एक स्वच्छ, अच्छी तरह से परिभाषित इंटरफ़ेस की अनुमति देते हैं।

हालांकि, कई तरीके हैं जो एक सर्वर और क्लाइंट संवाद कर सकते हैं, X(दूसरों द्वारा बताए गए लाभों की परवाह किए बिना) किया गया विकल्प अति-उपयोगी नहीं है: आप किसी अन्य मशीन पर सर्वर से कनेक्ट कर सकते हैं Xऔर अपने डेस्कटॉप पर विंडो खोल सकते हैं (या किसी अन्य सहयोगी पर) डेस्कटॉप)। यह उन दिनों में बहुत आम हुआ करता था जब एक्स विकसित किया गया था, जब कई विश्वविद्यालयों और व्यवसायों में एक यूनिक्स सर्वर और कई "एक्स टर्मिनल" होंगे जो इसके साथ बात करते थे। एक इंटरनेट-तैयार संचार प्रोटोकॉल का उपयोग करके, एक्स को मूल रूप से या मेजबान के भीतर उपयोग किया जा सकता है।

X पहला GUI वातावरण था जो एक कंप्यूटर पर एकल उपयोगकर्ता के लिए OS के बजाय बहु-उपयोगकर्ता वातावरण के रूप में UNIX के इतिहास के अनुरूप सुसंगत रूप से दूसरी मशीन से विंडो प्रदर्शित कर सकता था। यदि आप कभी-कभी आपके कंप्यूटर के साथ बातचीत (शारीरिक या दूरस्थ रूप से) करने वाले एकमात्र व्यक्ति हैं, तो यूनिक्स की बहुत सारी सुविधाएं ओवरकिल की तरह लगती हैं।

— एलेक्सिस
स्रोत

-1

मेरा मानना है कि x- सर्वर को क्लाइंट-सर्वर आर्किटेक्चर के रूप में डिजाइन किया गया था क्योंकि शुरू में कंप्यूटिंग संसाधन दुर्लभ थे और मेनफ्रेम ने अधिकांश भारी उठाने का काम किया था। एक्स-टर्मिनल्स केवल पतले ग्राहक थे जो एक्स-सर्वर से जुड़े थे और जो कुछ भी उपयोगकर्ता को प्रदर्शित करने की आवश्यकता थी, उसे प्रदर्शित किया गया।

इसके बहुत सारे लाभ हैं (आजकल एक्स के लिए संचार प्रोटोकॉल बहुत भारी है), विशेष रूप से आप कई ग्राहकों पर एक ही डिस्प्ले प्रदर्शित कर सकते हैं, कई उपयोगकर्ताओं के साथ स्क्रीन साझा करना एक्स में आसान है।

— कार्नी ली
स्रोत

X विंडो के लोकप्रिय होने के कई साल बाद X टर्मिनल्स आए, इसलिए वे इस कारण नहीं हो सके कि X विंडो को इस तरह से आर्किटेक्चर किया गया था। एक और बिंदु: एक्स टर्मिनल एक्स सर्वर से कनेक्ट नहीं थे, वे एक्स सर्वर चला रहे थे।

— जूलियाग्रे