LINUX.ORG.RU

Обновился инструмент для работы с агентами в C++: SObjectizer 5.5.5

 , , ,


1

2

SObjectizer — это небольшой фреймворк для упрощения разработки многопоточных приложений на C++. SObjectizer позволяет создавать объекты-агенты, которые взаимодействуют друг с другом только посредством асинхронных сообщений. Сам SObjectizer берет на себя задачи диспетчеризации сообщений и предоставление агентам рабочего контекста для обработки получаемых сообщений.

Проект живет на SourceForge, распространяется под трехпунктной BSD-лицензией.

Версию 5.5.5 можно взять либо из секции Files на SF, либо из Svn-репозитория, либо из зеркала на GitHub.

Если говорить кратко, то в версии 5.5.5 появилось следующее:

  • вспомогательные шаблонные методы introduce_coop и introduce_child_coop, упрощающие создание и регистрацию коопераций;
  • возможность использования туплов в качестве типов сообщений;
  • фильтры для сообщений, которые позволяют анализировать содержимое сообщений и отбрасывать те из них, которые не интересны агенту получателю;
  • несколько новых примеров.

Так же подготовлены две новые части серии презентаций “Dive into SObjectizer-5.5”, более подробно рассказывающие о состояниях агентов и кооперациях агентов (все имеющиеся презентации собраны здесь).

Если интересны подробности, то сюда.

Отдельная благодарность Алексею Сырникову, как за помощь в подготовке этого релиза, так и за поддержку зеркала SObjectizer на GitHub-е.

★★★★★

Круто. А кто авторы проекта? И насколько экспериментальна поддержка сборки CMake?

Кстати, отсюда:

message(FATAL_ERROR «Your C++ compiler does not supported.\nPlease mail me on san@masterspline.net Your compiler ID '${CMAKE_CXX_COMPILER_ID}' and this error message.»)

сразу видно, что авторы русскоязычные)

asaw ★★★★★
()
Ответ на: комментарий от asaw

А кто авторы проекта?

Я + еще несколько моих бывших коллег.

И насколько экспериментальна поддержка сборки CMake?

Поддержка CMake была добавлена Алексеем Сырниковым. С тех пор мы стараемся поддерживать CMake-скрипты в актуальном состоянии, вроде бы получается. Жалоб пока не было.

Перед релизом сборка посредством CMake проверяется под FreeBSD и clang, а так же под Linux и GCC.

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

сразу видно, что авторы русскоязычные)

Ага, есть такое дело :)

eao197 ★★★★★
() автор топика

«Шо, опять?» (с)

Напоминает чем-то: «Данила строгает ножиком транзистор... Данила стругает рубанком ножик...» (с) (А когда коту делать нечего...)

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

Кто-нибудь этим пользуется?

Пользуются.

Истории успеха не видать,

Про открытые проекты на SO-5 мне не ведомо. Рассказывать про закрытые довольно стремно, ибо к компании, в которой SO-5 используется, отношения уже не имею. Нет желания нарываться.

но аттеншонвхоринг регулярный.

Проект открытый, под Linux-ом работает. Полагаю, если бы подобными анонсами правила LOR-а нарушались, администрация ресурса уже бы высказала бы свое мнение.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

«У нас есть такие приборы, но мы вам про них не расскажем...» (с) «Ну вот и вы говорите» (с)

администрация ресурса уже бы высказала бы свое мнение.

МВИМ - тоже мнение, высказанное на ресурсе неоднократно (мнение оно у всех есть, такова селяви) :)

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

«У нас есть такие приборы, но мы вам про них не расскажем...» (с) «Ну вот и вы говорите» (с)

Ну если я скажу, что программные компоненты на основе SO-4/SO-5 использовались и используются в реализации систем мобильного банка для ряда крупных российских и не только банков (например, Сбербанк в РФ, Халык-банк в Казахстане), в платформах мобильной коммерции для крупных сотовых операторов (МТС, Мегафон), в системе оплаты сотовой связи для одного из крупнейших банков РФ, в платформе агрегации SMS/USSD-трафика с поддержкой SMS-рассылок объемом в сотни миллионов сообщений (и с подключениями более чем к 30 операторам сотовой связи в странах СНГ и Восточной Европе)... Но не смогу рассказать о деталях, т.к. это под NDA, вам станет легче?

eao197 ★★★★★
() автор топика

Зачем пытаться прилепить к говну модель акторов, если есть языки, которые поддерживают ее естественным образом, семантически? Не лучше ли оставить говно в покое, пусть плавает в своем свободном плавании, а конкурентные системы писать на нормальных ЯП?

anonymous
()
Ответ на: комментарий от asaw

Сферических, в вакууме))

Я бы предпочел услышать «правильный ответ» :)

Есть, конечно, Erlang. Но это динамика, да еще и не очень шустрая. Да еще и ставшая популярной не так давно. Да еще в последнее время попадаются на глаза реплики о разочаровании в Erlang-е, наступающем после первоначального энтузиазма.

Был еще язык E, но вряд ли он вышел за пределы очень узкого круга пользователей.

Хотя есть у меня серьезное подозрение, что аноним говорил о каком-то варианте Lisp-а :)

eao197 ★★★★★
() автор топика
Ответ на: комментарий от basp

go

Это не модель акторов. Go дает типизированные каналы. Если нужен «актор» которому следует работать с несколькими каналами, то это все нужно будет делать вручную.

Кроме того, отсутствие в Go нормального ООП, шаблонов и исключений, делает этот язык подходящим далеко не для всех. Впрочем, это к теме actor model не относится.

erlang

Это да. Но это динамика. Причем не самая производительная.

scala+akka

Это тоже самое, что и C++ в связке с SObjectizer, или C++ в связке с C++ Actor Framework.

eao197 ★★★★★
() автор топика

Каждый тред одно и то же. ТС, создай отдельную страницу-FAQ, где ответь на все стандартные вопросы: «где применяется», «ерланг рулит», «код говно» и т.д. Прикрепляй ссылку на него в этих своих новостных постах и не ведись на провокации.

staseg ★★★★★
()
Ответ на: комментарий от eao197

Хм, прочитать, о том, как написать FAQ? Если вопрос в том, где его разместить, то хоть на ЛОРе отдельной темой или файликом на гитхабе.

staseg ★★★★★
()
Ответ на: комментарий от staseg

Каждый тред одно и то же. ТС, создай отдельную страницу

Но, ведь тогда вообще никаких комментариев не будет. Раньше вон, хоть писали, что SF - аццтой, и вообще без ГитХаба жизни нет, собирать проект каким-то mxx не с руки и так на пару страниц. А щас тока и могут, что «английский не достаточно английский» или «тормозной эрланг да Жава-акка круче».

Кста, по поводу «код - говно». Код проекта проверяется регулярно coverity (который даже при первом прогоне ничего подозрительного не нашел).

anonymous
()
Ответ на: комментарий от staseg

отдельную страницу-FAQ

Я подумал, что речь идет о FAQ-е именно на ЛОР-е и что здесь есть для этого какие-то правила. Может есть какая-то инструкция или свод рекомендаций на этот счет.

А сделать FAQ в другом месте не проблема.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Зачем пытаться прилепить к говну модель акторов, если есть языки, которые поддерживают ее естественным образом, семантически? Не лучше ли оставить говно в покое, пусть плавает в своем свободном плавании, а конкурентные системы писать на нормальных ЯП?

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

anonymous
()
Ответ на: комментарий от anonymous

Кста, по поводу «код - говно». Код проекта проверяется регулярно coverity (который даже при первом прогоне ничего подозрительного не нашел).

Я имел в виду код самих акторов. Многословненько.

staseg ★★★★★
()
Последнее исправление: staseg (всего исправлений: 1)
Ответ на: комментарий от basp

go

Почти бессмысленный язык. Мода на него определенная есть, но она не оправдана, если смотреть на возможности языка. Кроме того, акторов там из коробки нет и нужно писать/использовать что-то библиотечное. сопрограммы на стероидах + каналы могут не все. Это несколько другая модель, чем акторы.

erlang

Клевый. Но не всегда и не везде. Динамическая типизация, не слишком быстрый ввод-вывод, не очень хорошая работа в географически-распределенных системах и пр. и пр.

scala+akka

Хорошее решение и хороший язык. Но не всегда мы разрабатываем для JVM. Нативность еще востребована.

anonymous
()
Ответ на: комментарий от staseg

Многословненько.

Уменьшению многословности постоянно уделяется много внимания. И обсуждения, в том числе и на LOR-е, сильно способствуют уменьшению многословности.

Так что любые замечания/предложения и идеи всячески приветствуются.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Кроме того, отсутствие в Go нормального ООП ... Впрочем, это к теме actor model не относится.

Еще как относится. Нормальная, бескостылная, реализация акторов возможна только в языке с чистым ООП, где все есть объект. Объект инкапсулирует состояние и поведение, актор инкапсулирует состояние, поведение и процессинг. Одно ложится на другое. Любая другая реализация — это уродство и костыли.

anonymous
()
Ответ на: комментарий от asaw

Вот, что писалось на эту тему около года назад:

http://eao197.blogspot.com/2014/07/progc-sobjectizer-libcppa.html

http://eao197.blogspot.com/2014/07/progc-libcppa.html

Думаю, что в плане актуальности ничего сильно не изменилось. Разве что, по моим наблюдениям, авторы CAF сейчас свой фреймворк несколько переделывают, так что его API видоизменяется от версии к версии.

Плюс, если нужна платформа Windows, то в CAF это только через MinGW. А SO-5 поддерживает MSVC++ 12.0 из коробки.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Отсюда получается, что SObjectizer более зрелый проект, хотя у CAF тоже есть некоторые свои преимущества. Но CAF качественнее распиарен. А взаимодействовать вы не пробовали?

asaw ★★★★★
()
Ответ на: комментарий от asaw

хотя у CAF тоже есть некоторые свои преимущества.

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

Когда история SObjectizer (тогда еще SCADA Objectizer) начиналась, я лично про actor model вообще не знал. Знакомство с этой моделью и, тем более, ее использование в качестве «красной тряпки» при анонсах релизов SO-5, произошло гораздо позже.

SObjectizer идет от задач, характерных для АСУТП (SCADA). Собственно, мне сегодня напомнили про одно из таких внедрений SO-4. Это очень похоже на то, для чего когда-то давно мы свою модель агентов и разрабатывали. Ключевыми чертами которой являлось представление агентов в виде конечных автоматов и предоставление агентам контекста, на котором агенты могут выполнять свои действия.

Кстати говоря, в 2002-м году мы решились потратить какое-то время на возрождение проекта Objectizer-а и разработку первой версии SO-4 после опыта написания небольшого GUI-приложения для работы с SIM-картами через PC/SC-ридеры. Там, пришлось вручную сделать часть того же самого механизма распределения работы между объектами и рабочими нитями, как мы это делали в SCADA Objectizer-е. Но очень примитивно. Зато после появления SO-4 такие вещи стали делаться много проще.

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

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

Поэтому я считаю, что SO — это инструмент для concurrent programming, да еще склоняющийся в сторону задач, похожих на управление внешними устройствами. Тогда как CAF — это инструмент для parallel programming, т.е. максимальная утилизация вычислительных ресурсов.

Насколько здесь возможна какая-то синергия — не знаю.

Как по мне, так пусть лучше каждый фреймворк развивается в своем направлении. В конце-концов, в мире C++ живых открытых проектов такого уровня всего два (SO-5 и CAF), так что места под Солнцем должно хватить всем.

Но CAF качественнее распиарен.

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

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

Да и для пиара нужно иметь талант. Чего, очевидно, у меня нет.

Но, надеюсь, терпение и время сделают свое дело.

А взаимодействовать вы не пробовали?

Нет. Не думаю, что разработчики CAF-а про нас вообще знают.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

используются в реализации систем мобильного банка для ряда крупных российских и не только банков (например, Сбербанк в РФ

Если какая-то вещь используется в Сбербанке, это хороший повод её обходить стороной.

hateyoufeel ★★★★★
()
Ответ на: комментарий от asaw

Вот, для ответа на вопрос на reddit-е пришлось написать очередное сравнение SO-5 с CAF. Более актуальное, т.к. CAF за последний год, как выясняется, довольно сильно изменился.

Написано, правда, на Runlish-е, но, надеюсь, основные вещи будут более-менее понятны :)

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Вот этот вот момент меня заинтересовал:

Network transparency was removed from SObjectizer-5 so the SObjectizer-5 itself has no facilities to build distributed applications. Externals libraries should be used in that case. This is a conscious decision.

То есть поддержку сети выкинули, но насколько сложно её сделать? Есть ли сериализация сообщений в не зависящий от архитектуры формат?

asaw ★★★★★
()
Ответ на: комментарий от asaw

То есть поддержку сети выкинули, но насколько сложно её сделать? Есть ли сериализация сообщений в не зависящий от архитектуры формат?

Тут довольно непростая история. В SO-4 поддержка распределенных приложений была реализована сразу в ядре SObjectizer. И уже на ее основе другие библиотеки реализовывали тот или иной функционал. Где-то это было удобно (например, при распространении мониторинговой информации наружу), где-то не очень (например, при реализации чего-то вроде MQ и publish/subscribe).

Поэтому в SO-5 было принято решение не реализовывать коммуникационные возможности в самом ядре SO-5. А вынести это во внешние библиотеки. Для того, чтобы эти библиотеки могли тесно интегрироваться с ядром SO, в SO-5 было добавлено такое понятие, как «слой» (layer). Идея была в том, что ядро SO есть у пользователя всегда, а вот дополнительную функциональность пользователь мог бы «наслаивать» на ядро по мере надобности.

Исходя из этой идеи были реализованы библиотеки so_transport и mbapi, которые как раз являлись layer-ами для SO. Библиотека mbapi предоставляла высокоуровневый механизм обмена сообщениями между агентами. При котором обеспечивалась та самая network transparency.

Однако, все это базировалось на ACE Framework. И до августа прошлого года релизы SO-5 представляли из себя релизы сборок (assemblies), в которые входили само ядро SO-5, а так же последние стабильные версии библиотек, разработанных над этим ядром (в том числе и so_transport, и mbapi). Вот, например, анонс последней такой сборки.

Но где-то в это время по ряду причин сильно уменьшились ресурсы, вовлеченные в разработку SO-5. Фактически, с тех пор разработка ведется силами одного человека. Понятное дело, что силы эти не безграничны.

Поэтому, после того, как ядро SO-5 было отвязано от ACE Framework, разработка дополнительных библиотек (т.к. so_transport и mbapi) остановилась. На то, чтобы возродить их и довести до ума (а там, к сожалению, не все было сделано хорошо с самого начала) просто нет ресурсов.

Кроме того, лично у меня есть большие сомнения в том, что транспортный слой должен делаться на самом SO-5. Ведь есть куча готовых инструментов с поддержкой различных транспортов (навскидку: ZeroMQ, nanomsg, MQTT, AMQP, DDS, не говоря уже о разных формах на базе HTTP (REST, XML-RPC, SOAP)) и способов сериализации данных (protobuf, thrief, boost.serialization, cereal, message pack и т.д.)... И зачем создавать еще что-то? Не лучше ли сосредоточиться на эффективном и мощном диспатчинге сообщений, а средства коммуникации предоставить тем, кто профессионально этим занимается?

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

eao197 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

нативность, управление памятью, эффективный код и пр.

да хоть на окамле, хоть на хаскеле хоть на асемблере бири и пеши уские места, лишь бы ffi был. песать на крестах веб серверы - это ж надо быть настолько умным.

anonymous
()
Ответ на: комментарий от anonymous

песать на крестах веб серверы - это ж надо быть настолько умным.

Гуглу это расскажите. Или Facebook-у, который и VM для PHP на C++ переписывает, и трансляцию из PHP в C++ делают.

А уж с развитием IoT, где совсем маломощные устройства будут RESTful-интерфейсы наружу выставлять, актуальности в написанных на C и C++ веб-серверах не будет вообще, от слова совсем, да. Грамотеи вроде вас будут начинку для таких устройств на OCaml-е с Haskell-ем писать, а узкие места на ассемблере через FFI реализовывать.

Удачи вам в ваших теплых и уютных фантазиях.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

в твоих мечтах.

Несколько месяцев назад случился эпичнейший флейм в dmzlj.livejournal. Как раз из-за того, что ув.dmz высказал свое «фи» по результатам нескольких лет использования Erlang-а. Флейм был насколько эпичным, что автор просто снес все содержимое своего ЖЖ после этого. Думаю, на ЛОР-е есть люди, которые имели удовольствие почитать, а может и поучаствовать в том сраче.

Из недавнего еще вот это можно отметить: http://eax.me/erlang-is-specific/

Ну а жалобы Erlang-еров на качество имеющихся библиотек — это вообще встречается сплошь и рядом.

eao197 ★★★★★
() автор топика

А интеграция с механизмов сигналов/слотов QT возможна? Т.е. есть у меня, допустим, много-много GUI-шных форм на QT, к которым я хочу добавить функциональность фреймворка из топика. Можно ли это безболезненно сделать?

anonymous
()
Ответ на: комментарий от anonymous

Мы делали такое в свое время в SObjectizer-4. Для Qt3 точно, и может быть, даже для Qt4. Выглядело это так:

  • был разработан специальный диспетчер, который использовал для диспетчеризации очередь событий самой Qt;
  • Qt-шный виджет, который хотел получать сообщения от SO-4, наследовался не только от Qt-шного класса (QWidget-а или чего-то подобного), но и от SO-шного agent_t;
  • такой Qt-виджет/SO-агент привязывался к специальному диспетчеру из первого пункта.

В итоге подобный Qt-виджет/SO-агент работал на главной нити приложения, но был обычным агентом, получал обычные сообщения и т.д.

Для SO-5 необходимости интегрироваться с Qt у нас не было пока. Не вижу препятствий в реализации подобного же механизма. Разве что за исключением выбора подходящей лицензии (т.к. Qt сейчас лицензируется сразу под тремя лицензиями и разобраться в этом хитросплетении без бутылки не получается ;))

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Забавно. Кажется, впервые в жизни может потребоваться множественное наследование)))Впрочем, поковыряю SO еще на досуге на предмет осознания нужно ли оно сейчас мне, или нет. Спасибо за ответ.

anonymous
()
Ответ на: комментарий от Deleted

поцоны не качайте!

Да, поцонам не качать ни в коем разе!

Для всех остальных есть зеркало на GitHub.

PS. Это мне кажется или на самом деле количество долбодятлов на LOR за последние годы выросло?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

количество долбодятлов на LOR за последние годы выросло?

да

Deleted
()
Ответ на: комментарий от anonymous

да хоть на окамле, хоть на хаскеле хоть на асемблере бири и пеши уские места, лишь бы ffi был. песать на крестах веб серверы - это ж надо быть настолько умным.

Т.е. ты предлагаешь мне писать на Си для ffi всяких маргинальных языков? И это на ровном месте? И кто после этого извращенец? Ты из-за религиозной слепой неприязни к инструменту сам городишь костыли на ровном месте. Глупо.

anonymous
()
Ответ на: комментарий от anonymous

поковыряю SO еще на досуге

Если будешь клонировать с GitHub git'ом, то там в readme написано, как это делать. В репозитории используются submodules, поэтому нужно клонировать рекурсивно, либо отдельно их подгружать.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.