`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрей Зубинский

Логика и терминальные системы

+55
голосов

Терминальные системы - штука интересная во многих смыслах.

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

Первые терминалы были по сути интерпретаторами некоторого простого командного языка. Целевой машиной для этого языка была как бы каретка (курсор), "ползающая" по полю из клеток размером 80*24 (или другому, не важно). С помощью языка можно было приказать каретке напечатать в клетке символ, стереть его, командовать перемещениями каретки в абсолютной системе координат (по всему полю) и относительной (например, относительно текущего положения каретки). Ну и всякое еще.

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

Затем - X-терминалы. Уровень протокола, на основании которого строилось общение хоста и терминала, стал еще выше.

И...

И все.
Точка реализации "в железе" интерпретатора, исполняющего X-протокол на целевой машине растрового графического дисплея, стала точкой перегиба.

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

Вот здесь уже можно задать вопрос - почему разработчики отказались от повышения интеллекта терминала (усложнения понимаемого им языка) и пошли по пути принципиального упрощения?
Однозначно верного ответа быть не может, но соображения кое-какие есть.
Во-первых, вполне возможно, что так поступить - правильно. Потому что начиная с какого-то уровня сложности протокола передача обновленных кусочков буфера кадра может оказаться более эффективной.
Во-вторых, - потому что невозможно создать единственный графический API на все случаи жизни и отобразить его вызовы на единственно верный язык и протокол общения хоста и графического терминала.
В-третьих, - потому что рост сложности языка и протокола приводит к росту сложности реализаций, а она - к снижению безопасности. Знаменитые эксплойты X Window надолго остались в памяти.
Можно придумать ещё несколько пунктов.

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

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

Кстати, алфавитно-цифровые терминалы никуда не делись.
И производятся.
Причём, что самое интересное - в том числе и компанией, купившей в своё время у почившей DEC... терминальный бизнес.
Такой вот парадокс - DEC уже давно нет, а в свое время (в 1995 г.) прикупившая кусочек гиганта SunRiver Data Systems переименовалась и живёт и здравствует до сих пор.

+55
голосов

Напечатать Отправить другу

Читайте также

Удалено мною (avl http://ko-online.com.ua/user/2437), как эмоциональное не законченное и не относящееся к статье сообщение.

А что там у Plan9 было? Там ведь можно было получить доступ к устройствам по сети? Открываем доступ к виртуальной видеокарте для сервера и он рисует все через нее.

Да и RDC от MS по моему использует абстракцию примитивов GDI для передачи информации, а не абстракцию фрейм-буфера.

RDP - да, я его упустил из виду, он действительно транслирует GDI-вызовы. но он как раз попадает в логику снижения интеллектуальности терминалов.

да и это вообще несущественно в контексте - всё равно ресурсы графического акселератора не разделить. в первую очередь, всё, что касается 3D. GDI ведь совершенно примитивная штука, и чтобы отобразить что-то трёхмерное, всё равно придётся "молотить" основными процессорами те вычисления, которые в рабочей станции акселерированы GPU видеокарты.

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

в общем, если нужны CAD, нужны рабочие станции.
вариантов нет.

Андрей,
если рассматривать вариант, когда ПО выполняется на сервере, а 3D графика отображается на клиенте. То это не целесообразно, по моему. Во-первых, это сильная связь: PCIe-16 зачем то ведь понадобилась. Во-вторых, что это за тонкий клиент будет с мощной 3D видео-картой.

в общем, если нужны CAD, нужны рабочие станции. с этим согласен.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT