Я никогда не понимал, зачем оконной системе нужен сервер. Зачем окружениям рабочего стола, менеджерам дисплеев и оконным менеджерам нужен xorg-server? Только для того, чтобы иметь слой абстракции поверх графической карты? Почему оконные системы используют модель клиент-сервер? Не будет ли проще межпроцессное взаимодействие через именованные каналы?
решение1
Я думаю, вы уже заметили, что необходим какой-то "сервер". Каждый клиент (среда рабочего стола, менеджер окон или оконная программа) должен делиться дисплеем со всеми остальными, и они должны иметь возможность отображать что-либо, не зная деталей оборудования или не зная, кто еще использует дисплей. Поэтому сервер X11 обеспечивает упомянутый вами уровень абстракции и совместного использования, предоставляя интерфейс IPC.
X11, вероятно, можно заставить работать через именованные каналы, но есть две важные вещи, которые именованные каналы делать не могут.
- Именованные каналы взаимодействуют только в одном направлении.
- Если два процесса начнут помещать данные в «отправляющий» конец именованного канала, данные перемешаются.
Фактически, большинство клиентов X общаются с сервером, используя "новый и улучшенный" именованный канал, называемый сокетом домена UNIX. Он во многом похож на именованный канал, за исключением того, что он позволяет процессам общаться в обоих направлениях и отслеживает, кто что сказал. Это те же самые вещи, которые должна делать сеть, и поэтому сокеты домена UNIX используют тот же программный интерфейс, что и сокеты TCP/IP, которые обеспечивают сетевые коммуникации.
Но с этого момента очень легко сказать: «А что, если я запущу сервер на другом хосте, нежели клиент?» Просто используйте сокет TCP вместо сокета UNIX, и вуаля: протокол удаленного рабочего стола, который старше Windows RDP на десятилетия. Я могу подключиться sshк четырем различным удаленным хостам и запустить synaptic(графический менеджер пакетов) на каждом из них, и все четыре окна появятся на дисплее моего локального компьютера.
решение2
Оконная система не обязательно должна иметь сервер, но вы можете решить реализовать оконную систему на основе клиент-серверной модели. Это имеет несколько преимуществ, поскольку вы четко разделяете действия на клиенте и сервере, им не нужно работать на одной машине, и это упрощает обслуживание нескольких клиентов. В настоящее время это все еще очень удобно (например, когда вы sshпереходите на другую машину), но вы должны понимать, что во время разработки X это считалось необходимостью: ваша локальная машина могла быть недостаточно мощной для запуска клиента.
Именованные каналы не дадут вам автоматического преимущества в виде возможности работать по сети, как это сделала бы реализация TCP. Но именованные каналы были, например, недоступны в DOS, с DosExtender, работающим на Desqview/X (1992), и, насколько мне известно, также не доступны в VMS. Для этих реализаций специфическая для Unix связь была бы проблемой.
TCP не является специфичным для Unix, и можно запустить клиент под VAX/VMS (разработка X началась в 1984 году) и вывести вывод на локальную графическую рабочую станцию на базе UNIX. Из "X Window System: The Complete Reference to Xlib, X Protocol, ICCCM, XLFD"¹:
Осенью 1986 года Digital решила основать всю свою стратегию настольных рабочих станций для ULTRIX, VMS и MS-DOS на X. Хотя это было приятно для нас, это также означало, что нам нужно было поговорить с еще большим количеством людей. Это привело к некоторой задержке, но, в конечном итоге, также привело к лучшему дизайну. Ральф Суик из Digital присоединился к Project Athena в этот период и сыграл важную роль в разработке версии 11. Последний выпуск версии 10 был выпущен в декабре 1986 года.
Из «Справочного руководства по протоколу X»²:
Разделение обязанностей
В процессе проектирования протокола X много внимания уделялось разделению возможностей между сервером и клиентом, поскольку это определяет, какая информация должна передаваться туда и обратно через запросы, ответы и события. Превосходным источником информации о логике определенных выборов, сделанных при проектировании протокола, является статья The X Window System Роберта В. Шейфлера и Джима Геттиса, опубликованная в журнале Ассоциации вычислительной техники Transaction on Graphics, том 5, № 2, апрель 1986 г. В конечном итоге принятые решения основывались на переносимости клиентских программ, простоте программирования клиентов и производительности.
Во-первых, сервер спроектирован таким образом, чтобы максимально скрыть различия в базовом оборудовании от клиентских приложений. ...
Я помню, что статья в TOG была интересным чтением. Она, безусловно, пробудила мой интерес к X и (это было до WorldWideWeb) к трудностям, с которыми мы сталкивались, чтобы получить больше информации, пока O'Reilly не начали публиковать свою серию книг X.
¹ X Версия 11, Выпуск 4, страница 2-X, PDF доступен онлайнздесь
² Это со страницы 9 2-го издания, опубликованного O'Reilly, которое я купил в 1990 году. Есть более новые издания, но я никогда не удосужился их купить, и они, насколько мне известно, также доступны только в бумажном виде. Я не думаю, что они изменили обоснование разделения обязанностей.
решение3
Система окон означает, что несколько независимых программ совместно используют общий ресурс, экран и устройства ввода. Общие ресурсы могут быть безопасно реализованы только двумя способами:
- Ресурс может контролироваться ядром, и приложения выполняют вызовы ядра для доступа к нему.
- Ресурс может контролироваться выделенным процессом (сервером), и приложения обращаются к серверу для доступа к нему.
Конечно, доступ к реальному оборудованию дисплея контролируется ядром, но для оконной системы этого недостаточно: должен быть способ, с помощью которого процессу может быть назначен определенныйчастьдисплея (окна), где можно быть уверенным, что никакой другой процесс не помешает, и должен быть определенный уровень защиты того, какое приложение может получить доступ к какой части ресурса и в какое время.
Теперь все это можно было бы перенести в ядро, что, насколько мне известно, делает Windows. Это имеет преимущество в том, что быстрее (обычно вызов ядра намного быстрее, чем обращение к другому процессу), однако имеет недостаток в том, что возможно открытие дыр в безопасности (любой эксплойт системы является эксплойтом на уровне ядра), и в то же время ограничивает переносимость (система, реализованная в ядре, сильно связана с ядром; вы не сможете легко перенести ее на другую операционную систему, и это совершенно невозможно сделать, если у вас нет доступа к коду ядра).
Если вы не хотите реализовывать его в ядре, единственный другой способ реализовать его — как выделенный процесс, то есть сервер. Обратите внимание, что сервер, к которому обращаются через именованные каналы, все еще является сервером. Кроме того, при запуске на одной машине большая часть коммуникации между X-сервером и клиентами в наши дни происходит через общую память; это все еще не меняет того факта, что сервер отображения является сервером.
Теперь, почему сервер связывается с помощью сокетов, а не с помощью именованных каналов? Ну, если вы делаете это с помощью сокетов, вам просто нужно иметь один сокет для всего сервера, который может выполнять все коммуникации. Если вы общаетесь с помощью каналов, вам нужно два канала на клиента. Помимо того, что управление всеми этими каналами было бы довольно обременительным, вы также можете столкнуться с некоторыми ограничениями операционной системы на количество открытых каналов, если достаточно много программ попытаются общаться с сервером одновременно.
И, конечно, еще одним преимуществом сокетов перед каналами является то, что с помощью сокетов можно устанавливать соединения между машинами, что было особенно важно во времена, когда компьютер использовался многими людьми, сидевшими за выделенными терминалами, поэтому программы на компьютере должны были взаимодействовать с различными терминалами. Однако даже сегодня это очень полезно в сетевых средах.
решение4
Клиент-серверные модели являются популярным дизайном для всех видов приложений, даже когда есть только один сервер и только один клиент. Они обеспечивают чистый, четко определенный интерфейс между доменами ответственности.
Хотя существует множество способов взаимодействия сервера и клиента, выбор, сделанный X(независимо от преимуществ, упомянутых другими), не является лишним: выможетподключиться к Xсерверу на другой машине и открыть окна на своем рабочем столе (или на другом рабочем столе, который взаимодействует с вами). Это было очень распространено в те дни, когда разрабатывался X, когда многие университеты и предприятия имели сервер Unix и множество «терминалов X», которые с ним общались.Благодаря использованию протокола связи, готового к выходу в Интернет, X можно беспрепятственно использовать как внутри хостов, так и между ними.
X была первой средой GUI, которая могла прозрачно отображать окна с другой машины, что соответствует истории UNIX как многопользовательской среды, а не ОС для одного пользователя на одном компьютере. Многие функции UNIX кажутся излишними, если вы единственный человек, который когда-либо взаимодействовал (физически или удаленно) с вашим компьютером.