Чому система X Window використовує сервер?

Я ніколи не розумів, чому у віконній системі повинен бути сервер. Чому для робочого середовища, менеджерів дисплеїв та менеджерів вікон потрібен xorg-сервер? Це лише мати шар абстракції поверх відеокарти? Чому віконні системи використовують модель клієнт-сервер? Чи не буде міжпроцесовий зв'язок через названі труби простішим?

Я думаю, ви вже помітили, що потрібен якийсь «сервер». Кожен клієнт (середовище робочого столу, менеджер вікон або програма з віконцями) повинен ділитися дисплеєм з усіма іншими, і вони повинні мати можливість відображати речі, не знаючи деталей апаратного забезпечення або не знаючи, хто ще використовує дисплей. Таким чином, сервер X11 забезпечує шар абстрагування та обміну, який ви згадали, надаючи інтерфейс IPC.

X11, ймовірно, може бути зроблений для запуску названих труб, але є дві великі речі, які з іменованими трубами не можуть зробити.

• Названі труби спілкуються лише в одному напрямку.
• Якщо два процеси почнуть вводити дані в кінець "відправки" названої труби, дані будуть перемішуватися.

Насправді більшість клієнтів X розмовляють із сервером за допомогою "нової та вдосконаленої" каналу з назвою UNIX-сокет. Це дуже схоже на названу трубу, за винятком того, що вона дозволяє процесам говорити в обох напрямках, і вона відслідковує, хто що сказав. Це ті самі речі, що має робити мережа, і тому розетки домену UNIX використовують той же інтерфейс програмування, що і сокети TCP / IP, які забезпечують мережевий зв’язок.

Але звідси дуже просто сказати "Що робити, якщо я запустив сервер на іншому хості, ніж клієнт?" Просто використовуйте сокет TCP замість сокета UNIX і voila: протокол віддаленого робочого столу, який передував Windows RDP десятиліттями. Я можу sshмати чотири різних віддалених хостів і запускати synaptic(графічний менеджер пакунків) на кожному з них, і всі чотири вікна з’являються на дисплеї мого локального комп’ютера.

У віконній системі не повинно бути сервера, але ви можете вирішити впровадити віконну систему на основі моделі клієнт-сервер. Це має ряд переваг, оскільки ви чітко розмежовуєте діяльність клієнта та сервера, їм не потрібно запускатись на одній машині і легше обслуговувати декілька клієнтів. Наразі це все ще дуже зручно (наприклад, коли ви sshпотрапляєте на іншу машину), але ви повинні усвідомити, що в той час, коли розроблявся X, це розглядалося як необхідність: ваша локальна машина може бути недостатньо потужною для запуску клієнта.

Іменовані труби не дають вам автоматичної переваги можливості працювати через мережу, як це зробить реалізація TCP. Але названі канали, наприклад, недоступні в DOS, DosExtender працює під управлінням Desqview / X (1992), а AFAIK також не використовується у VMS. Для цих реалізацій проблемою буде специфічна комунікація для Unix.

TCP не є специфічним для Unix, і можна запускати клієнта під VAX / VMS (X розробка розпочата в 1984 році) і обслуговувати вихід на локальній графічній робочій станції UNIX. З "X Window System: Повна посилання на Xlib, X протокол, ICCCM, XLFD" ¹:

Восени 1986 року Digital вирішила базувати всю свою стратегію робочих станцій на робочому столі для ULTRIX, VMS та MS-DOS на X. Хоча це було нам приємно, це також означало, що ми маємо ще більше людей спілкуватися. Це призвело до деякої затримки, але, врешті-решт, це також призвело до кращого дизайну. У цей період Ральф Свік із Цифрового приєднався до проекту «Афіна» і відіграв важливу роль, хоча в розробці версії 11. Останній випуск версії 10 був опублікований у грудні 1986 року.

З "Довідника по X протоколу" ²:

Розподіл обов'язків

У процесі розробки протоколу X багато роздумів пішло на поділ можливостей між сервером і клієнтом, тому це визначає, яку інформацію потрібно передавати вперед і назад за допомогою запитів, відповідей та подій. Прекрасним джерелом інформації про обґрунтування певного вибору, зробленого при розробці протоколу, є стаття «X Window System» Роберта В. Шейфлера та Джима Геттіса, опублікована в журналі «Асоціація обчислювальної техніки» Transaction on Graphics, т. 5, вип. 2, квітень 1986 р. Рішення, які були прийняті в кінцевому підсумку, ґрунтувалися на переносимості клієнтських програм, простоті програмування клієнтів та ефективності.

По-перше, сервер розроблений, наскільки це можливо, щоб приховати відмінності базового обладнання від клієнтських додатків. ...

Я пам’ятаю, що стаття в TOG була цікавою прочитаною. Це, безумовно, викликало мій інтерес до X, і (це було до WorldWideWeb) труднощі, з якими ми мали покласти мою руку на більшу інформацію, поки O'Reilly не почав публікувати свої книги X серії.

¹ _{X Версія 11, випуск 4, сторінка 2-X, PDF доступна в Інтернеті тут}
² _{Це зі сторінки 9 у другому виданні, опублікованому O'Reilly, що я купив у 1990 році. Є новіші видання, але я ніколи не заважав купувати ці, і вони є AFAIK доступними лише на папері. Я не думаю, що вони змінили обґрунтування розподілу обов'язків.}

Віконна система означає, що декілька незалежних програм мають спільний ресурс, екран та пристрої введення. Спільні ресурси можна безпечно реалізувати лише двома способами:

• Ресурсом може управляти ядро, і програми здійснюють дзвінки ядра для доступу до нього.
• Ресурсом може управляти спеціалізований процес (сервер), і програми звертаються до сервера для доступу до нього.

Звичайно, доступ до власного обладнання для дисплея контролюється ядром, але цього недостатньо для системи вікон: Повинно бути способом, щоб процес призначив певну частину дисплея (вікно), де це може бути розумно впевнений, що жоден інший процес не завадить, і повинен бути певний рівень захисту того, яка програма може отримати доступ до якої частини ресурсу в цей час.

Тепер все це могло зайти в ядро, яке є AFAIK тим, що робить Windows. Це має перевагу в тому, що швидше (зазвичай виклик ядра набагато швидше, ніж звернення до іншого процесу), однак у нього є недолік, можливо, відкриття отворів у безпеці (будь-який подвиг системи є експлуатуванням на рівні ядра), і в той же час час обмежує портативність (система, реалізована в ядрі, сильно поєднана з ядром; ви не зможете легко перенести його в іншу операційну систему і абсолютно не зможете це зробити, якщо у вас немає доступу до коду ядра).

Якщо ви не хочете реалізувати його в ядрі, єдиний інший спосіб його реалізації - це виділений процес, тобто сервер. Зауважте, що сервер, до якого контактують через названі труби, все ще є сервером. Крім того, під час роботи на одній машині багато спілкування між сервером X і клієнтами відбувається через спільну пам'ять в ці дні; що все ще не змінює факту, що сервер відображення - це сервер.

Тепер, чому з сервером зв’язується за допомогою розеток, а не з використанням названих труб? Ну, якщо ви робите це за допомогою сокетів, вам просто потрібно мати один сокет для всього сервера, який може робити все спілкування. Якщо ви спілкуєтесь з трубами, вам потрібно дві труби на кожного клієнта. Окрім того, що керування усіма цими трубами було б досить громіздким, ви також можете досягти деяких обмежень операційної системи щодо кількості відкритих труб, якщо достатньо багато програм одночасно намагаються поговорити з сервером.

І звичайно, ще одна перевага розеток над трубами полягає в тому, що за допомогою розеток ви можете мати з'єднання між машинами, що було особливо важливо в той час, коли власний комп’ютер ділився багатьма людьми, що сиділи на спеціалізованих терміналах, тому програми на комп'ютері повинні були спілкуватися до різних терміналів, але це все ще дуже корисно навіть сьогодні в мережевих середовищах.

X спочатку розроблявся та підтримувався MIT І, це було з ліцензією MIT з відкритим кодом, не те, що насправді має значення.

Хоча ви сприймаєте це як нетрадиційне, подумайте на мить; як би ви пояснили вибір використання парадигми клієнт-сервер у складі програмного забезпечення? І, можливо, варто сказати генеральному директору ..

Ось як я навчився цінувати вибір у коледжі. У клієнт-сервер, сервер управляє ресурсами, і особливо , будь-які ресурси , які повинні бути спільно . Отже, сервер X - це процес, який обслуговує клієнтські програми, клавіатуру, мишу та фреймбуфер (або, як би ви не писали на екрані у своїй системі).

Хоча це не дуже правильно, менеджер вікон часто пояснюється так: Це просто та річ, яка ставить ручки та інші прикраси на рамку програми та вікна, діалоги тощо.

Моделі клієнт-сервер - це популярна конструкція для всіляких додатків, навіть коли існує лише один сервер і лише один клієнт. Вони дозволяють мати чіткий чітко визначений інтерфейс між сферами відповідальності.

Хоча сервер і клієнт можуть багато спілкуватися, вибір, зроблений X(незалежно від переваг, зазначених іншими), не є зайвим: ви можете підключитися до Xсервера на іншій машині та відкрити вікна на робочому столі (або на іншому співпрацюючій робочий стіл). Це було дуже часто в часи, коли розроблявся X, коли багато університетів та підприємств мали сервер Unix та багато "X-терміналів", які спілкувалися з ним. Використовуючи протокол зв'язку, готовий до Інтернету, X можна безперешкодно використовувати в межах хостів або через них.

X - це перше середовище GUI, яке могло прозоро відображати вікна з іншої машини, що відповідає історії UNIX як багатокористувацького середовища, а не ОС для одного користувача на одному комп’ютері. Багато UNIX-функцій здаються непосильними, якщо ви єдина людина, яка коли-небудь може взаємодіяти (фізично чи віддалено) з вашим комп'ютером.

Я вважаю, що x-сервер був розроблений як архітектура клієнт-сервер, оскільки спочатку обчислювальні ресурси були дефіцитними, а мейнфрейми зробили більшу частину важкого підйому. X-термінали були просто тонкими клієнтами, які підключалися до x-серверів і відображали все необхідне для відображення користувачеві.

Це має багато переваг (хоча протокол зв'язку для X зараз дуже важкий), зокрема, ви можете відображати один і той же дисплей на декількох клієнтах, обмін екраном з декількома користувачами легко в X.