Если бы дизайнером D-Bus был я...
Jul. 29th, 2008 11:37 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerОбщесистемная/общесессионная шина сообщений, по которой приложения могут общаться между собой - штука полезная.
К сожалению, существующий кандидат на роль такой шины - D-Bus обладает рядом недостатков, затрудняющих понимание и использование её авторами приложений, и делающих практически невозможным использование этой технологии пользователями, обустраивающими свою рабочую среду с помощью наколенных скриптов.
Я бы сделал немножко по-другому
Как принято в Unix, все есть файл. Поэтому шина сообщений с точки зрения программы представляет собой двунаправленный файловый дескриптор (например, сокет) куда посылаются сообщения и откуда они принимаются.
Шина имеет топологию "звезда" - есть некий процесс - менеджер шины, с которым соединяются все процессы, желающие по этой шине общаться, и который решает кому какие сообщения форвардить.
Каждый из процессов, пользующихся шиной идентифицируется уникальным именем. Имя имеет иерархическую структуру (somethig.something.else).
Имена бывают двух видов - уникальные, генерируемые менеджером шины в момент соединения клиента (uuid.ХХХХХХХ где XXXXХХ некая алфовитно-цифровая строка) и well-known, к которым можно обращаться, чтобы получить некий известный сервис.
Вообще говоря, если менеджер шины знает, что процесса, предоставляющего данный сервис в данный момент в системе/сессии нет, он имеет право этот процесс запустить, если знает как.
Сообщения представляют собой текстовые строки, завершающиеся символом newline. Синтаксис может быть любым - лисповские S-expression, Tcl-списки, аналог командной строки shell. Мне представляется наиболее разумным использование синтаксиса shell.
Во-первых, этот синтаксис наиболее понятен всем пользователям. Во-вторых, shell таки самый высокоуровневый из распространенных скриптовых языков, Парсить сообщение в таком синтаксисе в шелл-скрипте можно посредством
Естественно, никакой типизации. Все есть строка. А как эту строку интерпретировать - вопрос договоренности между клиентом и сервисом (опубликовнаного интерфейса). Причем на уровне семантики, а не синтаксиса.
Формат сообщения следующий
Если в качестве получателя указана звездочка, то это широковещательное сообщение, которое рассылается всем клиентам (если только они не попросили менеджер шины фильтровать широковещательные сообщения и данное сообщение под фильтр не попало.
Если клиент отправлеят менеджеру шины сообщение, не содержащее адреса отправителя, то менеджер, прежде чем отправить сообщение получателю подставляет туда уникальное имя клиента, присвоенное ему при соединении.
При коннекте к менеджеру клиент получает от него сообщение
т.е. клиенту сообщается какое уникальное имя ему присвоили.
Если клиент хочет зарегистрировать well-known имя, он посылает сообщение:
на которое может получить либо
либо
После успешной регистрации имени, все имена в иереархическом дереве имен, начинающиеся с этого имени, считаются принадлежащими данному клиенту.
Сообщения с конкретным получателем могут быть вызовами методов, или ответами на вызов. У ответа на вызов получателем, как правило, является uuid.XXXX (исключение см выше).
Любой клиент, зарегистрировавший имя должен поддерживать метод Help, который вызывается следующими способами
Возвращает текстовое описание того, что этот клиент делает (apropos)
Возвращает список вложенных объектов в данном поддереве имен, которые поддерживаются данным клиентом.
Возвращает список методов, которые можно вызывать
Возвращает список параметров указанного метода
Возвращает информацию о том, что данный метод возвращает
Список ошибок, которые может вернуть данный метод.
Сообщение, являющееся ответом на вызов метода выглядит как
или
Методы объекта manager (менеджера шины)
Hello (вызывается неявно при соединении)
RegisterName (см выше)
UnregisterName - отмена регистрации имени (при закрытии соединеия отменяются все имена, зарегистрированные данным клиентом)
Filter glob-patterns - установка фильтра на широковещательные сообщения. Шаблон предваренный восклицательным знаком означает "не посылать сообщения удовлетворяющей данному шаблону". Просто шаблон - "посылать только сообщения, удовлетворяющие данному шаблону".
Client имя - возвращает известную менеджеру информацию об указанном клиенте. По крайней мере пользователя-владельца соответствующего процесса.
Available имя - возвращает статус доступности указанного имени. Может быть либо active (процесс, зарегистрировавший такое имя, выполняется) startable - менеджер знает, как такой процесс запустить и unknown.
Monitor on/off- заправшивает/отменяет пересылку данному клиенту ВСЕХ сообщений, бегающих по шине, независимо от отправителя получателя.
Debug on/off - разрешает данному клиенту посылать сообщения от имени любого отправителя. Этот метод завершается успешно только если юзер-владелец клиента совпадает с юзером-владельцем процесса-менеджера.
Некоторые соглашения о пространстве имен:
hw.* такие имена должны использовать в качестве имен отправителей сообщения, которые сообщают о событиях с оборудованем.
net.* сервисы, работающие с сетевыми соединеиями и сообщения о событиях с сетью.
Запуск сервисов менеджером - для каждой шины (системной/сессионной) имеется некоторая директория, в которую помещаются скрипты, запускающие сервисы, запускаемые on-demand. Имя скрипта должно совпадать с именем, которое зарегистрирует запущенный сервис.
Процессы-гейты, обеспечивающие гейтование шины в другой транспорт (например, сообщения протокола X11) вписываются в эту систему совершенно прозрачным образом. Единственное что для каждого клиента, приконнектившегося к гейту, гейт должен вызвать
manager.Hello явным образом, чтобы получить для него uuid.
Назовем данную конструкцию мы E-Bus. Во-первых, это "неприлично" звучит, а я люблю аббревиатуры на грани фола. Во-вторых, это сокращение от easy bus, в третьих - E - следующая буква алфавита после D,
К сожалению, существующий кандидат на роль такой шины - D-Bus обладает рядом недостатков, затрудняющих понимание и использование её авторами приложений, и делающих практически невозможным использование этой технологии пользователями, обустраивающими свою рабочую среду с помощью наколенных скриптов.
Я бы сделал немножко по-другому
Как принято в Unix, все есть файл. Поэтому шина сообщений с точки зрения программы представляет собой двунаправленный файловый дескриптор (например, сокет) куда посылаются сообщения и откуда они принимаются.
Шина имеет топологию "звезда" - есть некий процесс - менеджер шины, с которым соединяются все процессы, желающие по этой шине общаться, и который решает кому какие сообщения форвардить.
Каждый из процессов, пользующихся шиной идентифицируется уникальным именем. Имя имеет иерархическую структуру (somethig.something.else).
Имена бывают двух видов - уникальные, генерируемые менеджером шины в момент соединения клиента (uuid.ХХХХХХХ где XXXXХХ некая алфовитно-цифровая строка) и well-known, к которым можно обращаться, чтобы получить некий известный сервис.
Вообще говоря, если менеджер шины знает, что процесса, предоставляющего данный сервис в данный момент в системе/сессии нет, он имеет право этот процесс запустить, если знает как.
Сообщения представляют собой текстовые строки, завершающиеся символом newline. Синтаксис может быть любым - лисповские S-expression, Tcl-списки, аналог командной строки shell. Мне представляется наиболее разумным использование синтаксиса shell.
Во-первых, этот синтаксис наиболее понятен всем пользователям. Во-вторых, shell таки самый высокоуровневый из распространенных скриптовых языков, Парсить сообщение в таком синтаксисе в шелл-скрипте можно посредством
read message set -- $message
Естественно, никакой типизации. Все есть строка. А как эту строку интерпретировать - вопрос договоренности между клиентом и сервисом (опубликовнаного интерфейса). Причем на уровне семантики, а не синтаксиса.
Формат сообщения следующий
отправитель:получатель параметры
Если в качестве получателя указана звездочка, то это широковещательное сообщение, которое рассылается всем клиентам (если только они не попросили менеджер шины фильтровать широковещательные сообщения и данное сообщение под фильтр не попало.
Если клиент отправлеят менеджеру шины сообщение, не содержащее адреса отправителя, то менеджер, прежде чем отправить сообщение получателю подставляет туда уникальное имя клиента, присвоенное ему при соединении.
При коннекте к менеджеру клиент получает от него сообщение
manager.Hello:uuid.XXXXXXX
т.е. клиенту сообщается какое уникальное имя ему присвоили.
Если клиент хочет зарегистрировать well-known имя, он посылает сообщение:
manager.RegisterName имя
на которое может получить либо
manager.RegisterName:имя ok
либо
manager.RegisterName:имя error "имя уже занято"
После успешной регистрации имени, все имена в иереархическом дереве имен, начинающиеся с этого имени, считаются принадлежащими данному клиенту.
Сообщения с конкретным получателем могут быть вызовами методов, или ответами на вызов. У ответа на вызов получателем, как правило, является uuid.XXXX (исключение см выше).
Любой клиент, зарегистрировавший имя должен поддерживать метод Help, который вызывается следующими способами
some.client.Help
Возвращает текстовое описание того, что этот клиент делает (apropos)
some.client.Help objects
Возвращает список вложенных объектов в данном поддереве имен, которые поддерживаются данным клиентом.
some.client.Help methods some.client.subobject.Help methods
Возвращает список методов, которые можно вызывать
some.client.Help parameters Имя
Возвращает список параметров указанного метода
some.client.Help retval Имя
Возвращает информацию о том, что данный метод возвращает
some.client.Help errors Имя
Список ошибок, которые может вернуть данный метод.
Сообщение, являющееся ответом на вызов метода выглядит как
some.client.Method:uuid.caller ok возвращаемые значения
или
some.client.Method:uuid.caller error сообщение об ошибке [машинно-читаемые данные об ошибке]
Методы объекта manager (менеджера шины)
Hello (вызывается неявно при соединении)
RegisterName (см выше)
UnregisterName - отмена регистрации имени (при закрытии соединеия отменяются все имена, зарегистрированные данным клиентом)
Filter glob-patterns - установка фильтра на широковещательные сообщения. Шаблон предваренный восклицательным знаком означает "не посылать сообщения удовлетворяющей данному шаблону". Просто шаблон - "посылать только сообщения, удовлетворяющие данному шаблону".
Client имя - возвращает известную менеджеру информацию об указанном клиенте. По крайней мере пользователя-владельца соответствующего процесса.
Available имя - возвращает статус доступности указанного имени. Может быть либо active (процесс, зарегистрировавший такое имя, выполняется) startable - менеджер знает, как такой процесс запустить и unknown.
Monitor on/off- заправшивает/отменяет пересылку данному клиенту ВСЕХ сообщений, бегающих по шине, независимо от отправителя получателя.
Debug on/off - разрешает данному клиенту посылать сообщения от имени любого отправителя. Этот метод завершается успешно только если юзер-владелец клиента совпадает с юзером-владельцем процесса-менеджера.
Некоторые соглашения о пространстве имен:
hw.* такие имена должны использовать в качестве имен отправителей сообщения, которые сообщают о событиях с оборудованем.
net.* сервисы, работающие с сетевыми соединеиями и сообщения о событиях с сетью.
Запуск сервисов менеджером - для каждой шины (системной/сессионной) имеется некоторая директория, в которую помещаются скрипты, запускающие сервисы, запускаемые on-demand. Имя скрипта должно совпадать с именем, которое зарегистрирует запущенный сервис.
Процессы-гейты, обеспечивающие гейтование шины в другой транспорт (например, сообщения протокола X11) вписываются в эту систему совершенно прозрачным образом. Единственное что для каждого клиента, приконнектившегося к гейту, гейт должен вызвать
manager.Hello явным образом, чтобы получить для него uuid.
Назовем данную конструкцию мы E-Bus. Во-первых, это "неприлично" звучит, а я люблю аббревиатуры на грани фола. Во-вторых, это сокращение от easy bus, в третьих - E - следующая буква алфавита после D,
no subject
Date: 2008-07-29 08:48 am (UTC)no subject
Date: 2008-07-29 08:51 am (UTC)А сама CORBA сложна не просто так - она все-таки функционально побогаче будет...
no subject
Date: 2008-07-29 08:56 am (UTC)а) для подобной шины скорость не критична.
б) существует много-много реализаций разбора командной строки в синтаксисе shell, и они писались умными людьми, а вот реализаций маршаллинга/демаршаллинга бинарного формата D-Bus существует мало, и они могут оказаться в итоге менее эффективными.
D-Bus - это решение, которое функционально близко к оптимуму. Как раз то, что нужно для десктоп систем. Если еще правильно определиться с тем, что такое десктоп и научиться гонять session bus по протоколу X11, то совсем хорошо. Но вот конкретика там могла бы быть и сильно проще, что я и попытался продемонстрировать.
no subject
Date: 2008-07-29 09:01 am (UTC)Не совсем. Во-первых, есть мобильные устройства, хилые процом. Во-вторых, когда на ?bus будут переводить все интеракции на десктопе - оно может начать проседать...
> и они могут оказаться в итоге менее эффективными.
Честно скажу - мне сложно представить код, работающий с бинарными данными тормознее, чем с шелловскими конструкциями. Это должен быть довольно поганый код...
> Но вот конкретика там могла бы быть и сильно проще
Архитектурно - да, проще, "юниксовее". Но вот идея с сохранением чисто текстового подхода кажется мне сомнительной, чрезмерной "роскошью".
no subject
Date: 2008-07-29 09:15 am (UTC)Ну не настолько хилые. Что-то я не видел ни одного мобильного устройства у которого был бы 25МHz проц. А Unix-машины с shell-ом и таким процом - видел.
Sparc IPC, например. И не только видел, но и работал.
Именно. Такой он там и есть.
А вот не надо так делать. Есть X11 с его развитыми средствами передачи PIXMAP, типизированными selection и ReparentWindow. Есть файловая система, через которую достаточно удобно передавать большие массивы данных.
Про создание out-of-band сокета тут уже написали.
no subject
Date: 2008-07-29 09:19 am (UTC)Мой консерн не в объеме данных у отдельно взятой пары "клиент-сервер" - а в кол-ве таких пар.
no subject
Date: 2008-07-29 10:59 am (UTC)no subject
Date: 2008-07-29 11:04 am (UTC)no subject
Date: 2008-07-29 02:49 pm (UTC)no subject
Date: 2008-07-29 03:51 pm (UTC)Кстати - главный D-Bus это который? Системный или сессионный?
no subject
Date: 2008-07-29 05:59 pm (UTC)http://davelargo.blogspot.com/2008/07/performance.html
Главный D-BUS -- это системный. Сейчас у него конкурентно 106 пользователей, то есть, 106 сессий.
no subject
Date: 2008-07-29 08:58 am (UTC)Если нужна скорость, то хватит одного метода дайМнеАдресСокетаДляКоннектаИПередачиБинарныхДанныхВЛюбимомМнойФормате, после которого *-bus будет не нужен.