Croquet
Материал из ALAS.
Croquet
Идея создания операционной системы Croquet проста по сути и трудно выполнима в части реализации. Звучит она примерно так: "Долой заплесневевшие технологии двадцати-тридцатилетней давности - мы создадим абсолютно новую ОС ХХІ века!". Звучит красиво, интригующе. Однако пока что заявления авторов остаются только словами, так как готового, а главное полноценного релиза системы нет (текущая тестовая версия 1.0 Beta – пока скорее интерфейс с расширенными возможностями, чем полноценная операционная система).
Тем не менее, логику создателей Croquet можно понять. Как уже говорилось, существующие ныне компьютерные технологии не загружают в большинстве случаев сами компьютеры. Исходя из этого, авторы Croquet разрабатывают полностью трехмерную операционную систему - причем делают акцент на возможности динамических изменений ее внешнего вида по желанию пользователя. Другими словами, это полностью динамическая среда, где легко создать свой собственный мир - и без малейших ограничений. В целом, задумка сразу наводит на мысль о том, что авторы Croquet - большие любители фантастических фильмов вообще и изображенных в них технологий будущего в частности. Согласно концепции, ОС Croquet не является "классической" операционкой - это трехмерный мир внутри компьютера, где таких понятий, как "ярлык" и "панель быстрого запуска", просто не существует.
Сroquet работает как виртуальная машина на любой из существующих ныне платформ. Причем, по заявлению авторов, мультиплатформенность Croquet значительно превосходит возможности виртуальной машины Java. Кроме того, система, написанная на языке Squeak (объектно-ориентированный язык, выросший из Smalltalk), является типичным детищем "братства open source".
Краткая информация
Прежде всего, по заявлениям разработчиков, Croquet - сетевая (в глобальном смысле этого слова) система, позволяющая работать с информацией любого рода практически в реальном времени, при этом для хранимых данных и методов их «использования» применяется объектная модель и объектные базы. Сами разработчики считают, что предложенная ими модель обработки/хранения/представления информации позволит строить системы гибкие и масштабируемые в пределах Мировой Паутины Также конструкция Croquet позволяет работать этой системе на компьютере любого типа с любой операционной системой (по личному опыту существующей на данный момент системе Open Croquet 1.0 beta требуется производительность не ниже 1,0 GHz)
Использование сетевой архитектуры приложения потребовало решения двух основных проблем масштабируемых систем:
- проблема n2: при обычном подключении для нового узла требуется установить n2 связей (модель подключения каждый к каждому, cross-point-switch). Идеология же Internet-сетей позволяет использование технологии peer-to-peer (основа «пиринговых» сетей), что фактически означает, что для организации подключения/передачи необходимо использование только лишь двух машин.
- 2n-проблема (supermassive 2n-problem): предположим в сети работает 100 пользователей, связей между ними 1002 = 10 000, но количество всевозможных подгрупп в этой сети оценивается числом 2100 ~ 1060 – что составляет немногим меньшим количества электронов во Вселенной. Таким образом, даже для небольшой сети с несколькими подгруппами решить задачу общего доступа к ресурсам с помощью централизованного управления не представляется возможным. Поскольку при разделении ресурсов пользователи хотят работать в режиме реального времени, то разработчики Croquet предложили в качестве решения задачи несколько модифицированный вариант пиринговой сети (рост времени не более, чем линейный). В рамках этого подхода разделяется по крайней мере три типа времени:
- Реальное время (real-time) тесно связано с пропускной способностью канала (здесь ключевым является тот факт, что невозможно достич полной синхронизации, а можно лишь вести разговор о наиболее близком подобии в силу ограниченной пропускной способности сети)
- Псевдо-время (pseudo-time) – время, соотнесенное с каждым объектом или системой объектов; единственное время, которое может быть совершенно определенным, независимым от ресурсов машины или возможностей сети.
- Время узла (node-time) – локальное время, за которое конкретная машина решает определенную задачу (в документации разработчиков применяется такты/секунда, что, вообще говоря, лежит в больших диапазонах в зависимости от производительности машин)
Изменение состояния объекта должно регистрироваться в режиме реального времени. Практически же, для работы синхронизации применяется симулируемое время – псевдо-время.
Положим теперь, что всякий объект представляется некой историей стабильных состояний. Это означает, что любой «наблюдатель» (даже сам объект «видит» только стабильные состояния). Таким образом, если объект обновляется, то в системе используется его предыдущее стабильное состояние.
Распределенные объекты (distributed objects, DistOb)
Для передачи объекта между машинами существует два пути:
- передача через т.н. прокси-объект (proxy-object), который будет заниматься маршрутизацией сообщений (входящих и исходящих) к корневому объекту на машине. Корневой объект сам генерирует и обрабатывает сообщения от запрашивающего. Это решение не является гибким и масштабируемым, так как корневой объект берет на себя роль сервера. Однако, есть ситуации, когда такой метод оправдан: примером может служить расчет задачи теплофизики или гидродинамики на сетке с миллиардами точек на каком-либо суперкомпьютере (хотя, учитывая современные тенденции, подобная задача может быть распараллелена между несколькими обычными машинами).
- Объект реально копирует себя (реплицирует) на каждую пользовательскую машину, причем реплика запускает процесс для поддержания координации/синхронизации в более-менее реальном времени. Процессы эти гарантируют, что от реплик одного и того же объекта не может быть получено двух разных ответов в результате синхронизации. Иными словами, этот обмен фактически транзакция с атомарными действиями, причем сам процесс скрыт от глаз пользователя и им могут быть представлены не только данные, но и действия.
Пример работы
Пусть с системой Croquet работает несколько пользователей, объединенных глобальной сетью. Каждый из пользователей «видит» сцену «от первого лица». Предположим, один из пользователей передвигает портал. Другие пользователи «видят» это и имеют возможность отреагировать: передвинуть этот же портал, закрыть его и т.п. Механизм взаимодействия, реализуемый Croquet следующий: пользователь A кликает на портал P; до того как кто-либо, включая самого A увидит какое-либо изменение, событие «портал P активирован пользователем A» пересылается всем пользователем сети, у которых раскрыты реплики портала P (P1, P2, …, где Pi это DistOb). Системы эти получают это сообщение в разные периоды реального времени. Само событие регистрируется в истории каждой реплики, и они начинают независимую будущей ситуации, причем завершается эта обработка до определенного времени, заданного в исходном сообщении deadline.
Таким образом, объекты реплики самостоятельно переходят в следующие (стабильные и одинаковые) состояния. Если же в процессе перехода в одной из реплик произошла ошибка, то действие либо откатывается, либо состояние реплики восстанавливается с конечных состояний других реплик. После перехода к новому состоянию всех реплик, сцена перерисовывается в соответствии с текущим моментом времени на всех репликах.
Этот подход также имеет и другое крупное преимущество – поведение каждой реплики может быть уникальным в рамках конкретной машины.
Детали реализации
Зададимся вопросом: как объекты «узнают» должны ли они обновить свои состояния или нет? Самый простой ответ – они должны как-то скоординироваться друг с другом, но этот подход оказывается неэффективным, рост времени обработки становится уже нелинейным. Разработчики Croquet предлагают для этого собственное решение – TeaTime, предполагающее наличие объекта, инициирующего синхронизацию: realtime в этом подходе соотносится с пользователем, наиболее удаленным (в терминах интернет); после того как от такого сообщения приходит сообщение об успехе/неудаче транзакции, выдается команда на координацию. Таким образом большее количество действий выполняется на машине конечного пользователя, а значит, время на отработку будет расти не более, чем линейно.
Многопользовательская архитектура реального времени TeaTime
TeaTime - это фундамент системы сообщений и синхронизации объект-объект.
Основной и наиболее значительной частью TeaTime является класс TObject, который является предком для прочих Tea-объектов.
Tea-объекты перенаправляют сообщения, адресованные к ним на все свои реплики в существующей сети. Протокол сообщений Croquet поддерживает координацию распределенной двухфазовой системы обновления состояний, используемой для контроля за процессом вычислений/действий. Сообщения могут динамически перенаправляться большему количеству пользователей для выдерживания указанного временного интервала. Эти свойства позволяют TeaTime поддерживать гетерогенные (как hardware, так и software) системы. Коротко, это framework, который может быть динамически изменен как в рамках приложения, так и между приложениями. Заголовок TeaTime и проблемы масштабирования. В отличие от идеи прокси-объектов и централизации управления, порождающих избыточный поток сообщений и ненужные синхронизации в TeaTime вместо потока сообщений, каждая машина содержит реплику объекта, а именно, описание состояния и поведения исходного объекта, причем «понимание» этой реплики целиком находится в ведении локальной машины.
Начало изменения объекта отмечается сообщением, получив которое каждая реплика самостоятельно производит изменения в соответствии с указанными в сообщении действиями (иногда возможен «прогноз» поведения), после чего синхронизирующий сигнал обходит все реплики и все узлы. Проведенные тесты показали, что на территории США среднее время обхода составляет 10-60мс, а путешествие сигнала от Лос-Анджелеса до Магдебурга займет чуть больше 100мс. Последний результат превосходит по скорости необходимую для 12 кадров/с скорость передачи (распозноваемую как «непрерывную» и «одновременную»).
Ключевые моменты подхода TeaTime
- Координируемая временная база, внедренная на уровне протокола сообщений (три типа времени), расчет относительно псевдо-времени.
- Реплицируемые версионные объекты – унифицированная репликация, вычисление и распределение результатов.
- Стратегии репликации – механизм репликации обособлен от семантики поведения объектов.
- Deadline – распределение сообщений с поддержкой реакций на ошибки.
- Координируемая двухфазовая система обновления версий, используемая для определения прогресса вычислений/действий во множестве мест, адаптируемая к локальным ресурсам.
Синхронные/асинхронные вычисления
Основной проблемой построения системы является необходимость координации множеств пользователей, работающих совместно и достаточно интенсивно.
Бессмысленно ожидать, что все пользователи получат отклик на свои действия в течении 10 мс. TeaTime предоставляет возможность синхронизации событий в той же мере, в которой возможно синхронизировать процесс ввода/вывода в конкретной системе.
Основой синхронизации ввода/вывода является координации операции ввода и вывода в соответствии с глобальным универсальным временем (синхронизируемым по всем узлам системы, т.н. псевдо-время).
Действия в объектах (и над объектами) существуют единовременно, а событие/действие в каждом объекте реализуется методами, адаптирующимися во времени. Внутренние состояния управляются историей состояний. Действия производятся в псевдо-времени и синхронизируются в порядке, соответствующем операциям ввода/вывода. Ввод/вывод существует в реальном времени и предоставляет координацию реального и псевдо- времени.
Перспективы Croquet-подхода
- Возможность создавать самостоятельные объекты с динамическим поведением, не управляемые внешними процессами и существующие в пространстве-времени.
- Код, исполнение которого управляется динамически способен выполняться быстрее, чем в статических системы (скорость выполнения зависит от конкретной системы).
- В Croquet легко добавить собственные стратегии для управления поведением.
- Устойчивость системы к сбоям. Каждый объект, каждая реплика содержат информацию для восстановления и историю прошлых состояний. Вдобавок, двухфазовая система обновления позволяет избежать конфликтов: на первом шаге рассчитываются все влияния, и лишь потом происходят реально видимые изменения.
- Принцип «ответственности» объекта за его изменение/поведение.
В сумме с гетерогенностью систем, независимостью от оборудования и установленного системного ПО система дает широкие возможности как пользователю, так и программисту.
Аналогия с Веб
Существующая система представляет собой совокупность трехмерных миров («пространства Croquet», Croquet-spaces), каждое из которых фактически является аналогом странички в Веб. Гиперпорталы Croquet – это аналоги гиперссылок, а закладки в Веб соответствуют «снимку состояний» (snapshot), фиксирующему пространство и положение в нем.
При активировании пользователем портала, пространство, которое не кешировалось на локальной машине, будет сохранено – по аналогии с посещением новых страниц в браузере. По сравнению с браузером, Croquet отличается чуть большим объемом пересылаемых данных (необходима пересылка текстур в jpeg-формате, что может быть рассмотрено как аналог картинок на сайтах).
Компоненты Croquet
Компоненты – основные «строительные единицы» Croquet.
На вершине иерархии компонентов стоит TObject, от него производятся объекты класса TFrame. Компоненты Croquet – подклассы TFrame. Сам TFrame по действию аналогичен фрейму в OpenGL.
Компонент может самостоятельно представлять какие-либо действия – начиная от обычного ответа при получении сообщения-события, и заканчивая сложными действия, меняющими в зависимости от времени основные параметры объекта. Этот последний тип действий называется в Croquet симуляцией. Существует два типа симуляций:
- Определение управляемого событием состояния объекта за время отрисовки, совпадающие с текущим realtime или с разницей текущего и прошлого TTime;
- Пересчет состояний всего пространства в отношении ко времени в прошлом.
Графическая архитектура
В основе графического движка Croquet лежит идея того, что программист может иметь полный доступ и контроль за графической библиотекой (в текущей реализации OpenGL); с другой стороны, программист должен иметь возможность легко, быстро и удобно построить требуемое расширение системы. Этот подход позволяет каждому – от новичка до 3d-гуру создавать уникальные графические объекты и элементы интерфейса, расширять систему без необходимости менять основу движка.
Каждому объекту соответствует матрица трансформации относительно родительского объекта в иерархии объектов и перерисовка осуществляется только по достижении сообщением на обновление этого объекта.
Менеджер событий
Обработчик событий отвечает за перехват пользовательских событий от клавиатуры, мыши и т.п. Интерфейс достаточно легко может быть расширен и изменен, но по умолчанию объект TCamera связан с объектом TPointer, обрабатывающим объекты под курсором мыши. События клавиатуры также по умолчанию связаны с текущим выбранным объектом.
Скрипты
В Croquet с целью увеличения эффективности программирования, встроен скриптовой язык, уровни детализации которого соответствуют уровню опытности пользователя от новичка до хакера. Таким образом каждый имеет возможность построить систему для себя. Скриптовой язык имеет следующие уровни:
- TFrame hierarchy – пользователю на этом уровне доступно манипулирование объектами Croquet на самом низком уровне.
- Скрипты для продвинутых пользователей - большинство изменений достигается с помощью модификаций и расширений существующего framework (изменение системных параметров, работа со встроенными механизмами фреймов напрямую не могут быть произведены на этом уровне). Большинство скриптов пишутся именно в этой области.
- Написание скриптов с помощью специальных интерфейсов и мастеров (наподобие Squeak eToys) – предназначено для новичков.
Перевод: atermath
--atermath 06:41, 22 мая 2006 (MSD)
