Почему система X Window использует сервер?

Я никогда не понимал, почему в оконной системе должен быть сервер. Зачем настольным средам, дисплеям и менеджерам окон нужен xorg-сервер? Это только слой абстракции поверх видеокарты? Почему оконные системы используют модель клиент-сервер? Разве межпроцессное взаимодействие через именованные каналы не будет проще?

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

X11, вероятно, можно было бы запустить по именованным каналам, но есть две большие вещи, которые именованные каналы не могут сделать.

• Именованные каналы общаются только в одном направлении.
• Если два процесса начнут помещать данные в конец «именованного канала», данные будут смешаны.

Фактически, большинство X-клиентов общаются с сервером, используя «новый и улучшенный» именованный канал, называемый сокетом домена UNIX. Это очень похоже на именованный канал, за исключением того, что он позволяет процессам общаться в обоих направлениях, и он отслеживает, кто что сказал. Это те же самые вещи, которые должна выполнять сеть, и поэтому сокеты домена UNIX используют тот же программный интерфейс, что и сокеты TCP / IP, которые обеспечивают сетевую связь.

Но оттуда очень легко сказать: «Что если я запустил сервер на другом хосте, чем клиент?» Просто используйте сокет TCP вместо сокета UNIX и вуаля: протокол удаленного рабочего стола, предшествующий 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 Protocol, ICCCM, XLFD» ¹:

Осенью 1986 года Digital решила основать всю свою стратегию для настольных рабочих станций для ULTRIX, VMS и MS-DOS на X. Хотя это было приятно для нас, это также означало, что у нас было еще больше людей для общения. Это привело к некоторой задержке, но, в конце концов, также привело к улучшению дизайна. В этот период Ральф Свик из Digital присоединился к Project Athena и сыграл важную роль в разработке версии 11. Последняя версия 10 была выпущена в декабре 1986 года.

Из «Справочного руководства по протоколу X» ²:

Разделение обязанностей

В процессе разработки протокола X много внимания уделялось разделению возможностей между сервером и клиентом, так как это определяет, какую информацию следует передавать взад и вперед через запросы, ответы и события. Отличным источником информации об обосновании некоторых решений, принимаемых при разработке протокола, является статья Роберта В. Шейфлера и Джима Геттиса «Система X Window», опубликованная в журнале «Transaction on Graphics» Ассоциации томов вычислительной техники, том 5, №. 2 апреля 1986 г. Решения, которые в конечном итоге были приняты, были основаны на переносимости клиентских программ, простоте клиентского программирования и производительности.

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

Я помню, что статья в TOG была интересной для чтения. Это, безусловно, вызвало мой интерес к X и (это было до WorldWideWeb) трудности, с которыми мы сталкивались, получая больше информации, пока О'Рейли не начал публиковать свои книги серии X.

¹ _{X Версия 11, Выпуск 4, стр. 2-X, PDF доступен здесь: здесь}
² _{Это страница 9 во 2-м издании, изданном O'Reilly, которое я купил в 1990 году. Есть более новые выпуски, но я никогда не удосужился купить эти и они AFAIK доступны только на бумаге, а также. Я не думаю, что они изменили обоснование разделения обязанностей.}

Оконная система означает, что несколько независимых программ совместно используют общий ресурс, экран и устройства ввода. Совместно используемые ресурсы могут быть безопасно реализованы только двумя способами:

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

Конечно, доступ к фактическому оборудованию дисплея контролируется ядром, но этого недостаточно для оконной системы: у процесса должен быть способ назначить определенную часть дисплея (окна), где это может быть разумно убедитесь, что никакой другой процесс не будет мешать, и должен быть определенный уровень защиты того, какое приложение может получить доступ к какой части ресурса в какое время.

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

Если вы не хотите реализовывать его в ядре, единственный способ реализовать его - это выделенный процесс, то есть сервер. Обратите внимание, что сервер, с которым связываются через именованные каналы, по-прежнему является сервером. Кроме того, при работе на одной и той же машине большая часть обмена данными между X-сервером и клиентами происходит в наши дни через общую память; это по-прежнему не меняет того факта, что сервер дисплея является сервером.

Теперь, почему сервер связывается с использованием сокетов, а не с использованием именованных каналов? Что ж, если вы делаете это с помощью сокетов, вам просто нужно иметь один сокет для всего сервера, который может выполнять всю связь. Если вы общаетесь с каналами, вам нужно два канала для каждого клиента. Помимо того факта, что управление всеми этими каналами было бы довольно обременительным, вы также можете столкнуться с некоторыми ограничениями операционной системы на число открытых каналов, если достаточно много программ пытаются одновременно взаимодействовать с сервером.

И, конечно, еще одно преимущество сокетов над каналами состоит в том, что с сокетами вы можете иметь соединения между компьютерами, что было особенно важно в то время, когда фактический компьютер использовался многими людьми, сидящими на выделенных терминалах, поэтому программы на компьютере должны были обмениваться данными. к различным терминалам, но это все еще очень полезно даже сегодня в сетевых средах.

Первоначально X был разработан, разработан и поддерживается MIT И это было с лицензией MIT с открытым исходным кодом, не то, что действительно имеет значение.

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

Вот как я научился ценить выбор в колледже. В клиент-сервер сервер управляет ресурсами, и особенно , любые ресурсы, которые должны быть разделены . Итак, X-сервер - это процесс, который обслуживает клиентские приложения, клавиатуру, мышь и кадровый буфер (или, как бы вы ни писали на экран в вашей системе).

Хотя оконный менеджер не совсем корректен, его часто объясняют так: просто эта штука помещает маркеры и другие украшения в фрейм приложения, а также окна, диалоги и т. Д.

Модели клиент-сервер являются популярным дизайном для всех видов приложений, даже когда есть только один сервер и только один клиент. Они обеспечивают чистый, четко определенный интерфейс между областями ответственности.

Хотя существует множество способов взаимодействия сервера и клиента, выбор X(независимо от преимуществ, упомянутых другими) не является лишним: вы можете подключиться к Xсерверу на другом компьютере и открыть окна на рабочем столе (или на другом совместном компьютере). рабочий стол). Раньше это было очень распространено в те дни, когда разрабатывался X, когда во многих университетах и ​​компаниях был Unix-сервер и множество «X-терминалов», которые говорили с ним. Используя протокол связи, готовый к работе в Интернете, X можно беспрепятственно использовать внутри или между хостами.

X была первой средой с графическим интерфейсом, которая могла прозрачно отображать окна с другого компьютера, что соответствовало истории UNIX как многопользовательской среды, а не ОС для одного пользователя на одном компьютере. Многие функции UNIX кажутся излишними, если вы единственный человек, который когда-либо взаимодействует (физически или удаленно) с вашим компьютером.

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

Он имеет много преимуществ (хотя в настоящее время протокол связи для X очень тяжелый), в частности, вы можете отображать один и тот же дисплей на нескольких клиентах, а совместное использование экрана несколькими пользователями в X легко.