Здравствуйте, eao197, Вы писали:

E>Пока же предварительные замеры показывают следующее: на нутбуке Intel Pentium M 1.5GHz, 512Mb SObjectizer показывает пропускную способность в ~66K сообщений в секунду (под Windows XP и Visual C++ 7.1 и Slackware Linux 10.2 и GCC 3.3.2).

А что именно замерялось?

Здравствуйте, remark, Вы писали:

R>>>По сокету можно передавать ~40К сообщений в секунду в обе стороны одновременно (пробовал в обычной локалке Ethernet 100).

E>>Теперь добавь сюда сохранение каждого принятого сообщения в БД и логирование факта его приема и цифра уменьшится на порядок
R>Я же написал выше, что Oracle, стоящий на ПК, запросто сохраняет по 10К сообщений в секунду.

Ранее говорилось

Автор: remark
Дата: 03.08.06

про 100K сообщений

Но все равно, при необходимости записи сообщений в базу пропускная способность снижается с 40K до 10K, т.е. в четыре раза

R>Зачем логировать при нормальной работе?

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

E>>Кстати, какого размера были сообщения? Передавались ли они в синхронном или асинхронном режиме?
R>По 100 байт в синхронном режиме (через send/recv)

Т.е. использовался датаграмный режим?

R>Но всё равно хороший аллокатор памяти не повредит

Да. Только его еще сделать нужно и внедрить

Здравствуйте, eao197

E>Может быть вы предложите какой-нибудь несложный имитационный тест, который мы бы попытались запрограммировать в SObjectizer и замерить его производительность? А затем бы опубликовали как результаты замеров, так и исходные тексты теста.

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

E>Если не сложно, не могли бы вы сказать, откуда вы узнали про существование SObjectizer?

Вот из этого интереснейшего топика.

E>Если вы ознакомились с документацией/статьями о SObjectizer, то как вы находите их качество? Что, по вашему мнению, можно было бы улучшить?

Очень понравилось соотношение: "теория / описание примеров" в вашей книге "SObjectizer-4 Book".
Вот все б так писали

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, remark, Вы писали:

R>>>>По сокету можно передавать ~40К сообщений в секунду в обе стороны одновременно (пробовал в обычной локалке Ethernet 100).

E>>>Теперь добавь сюда сохранение каждого принятого сообщения в БД и логирование факта его приема и цифра уменьшится на порядок
R>>Я же написал выше, что Oracle, стоящий на ПК, запросто сохраняет по 10К сообщений в секунду.

E>Ранее говорилось

Автор: remark
Дата: 03.08.06

про 100K сообщений

Не сообщений, а записей
Записи были во-первых короче среднестатистических сообщений, а во-вторых клались в неиндексированную таблицу.
Поэтому сообщений не 100K, а 10K.


E>Но все равно, при необходимости записи сообщений в базу пропускная способность снижается с 40K до 10K, т.е. в четыре раза

Про требования пропускать через маршрутизатор 10K в секунду никто не говорил. Я имею в виду, что не БД, ни сокет вполне может не быть узким местом при требованиях в 3К. Ещё время и на обработку останется.


E>>>Кстати, какого размера были сообщения? Передавались ли они в синхронном или асинхронном режиме?
R>>По 100 байт в синхронном режиме (через send/recv)

E>Т.е. использовался датаграмный режим?

Нет, tcp. Но асинхронный ввод/вывод не использовался.


R>>Но всё равно хороший аллокатор памяти не повредит

E>Да. Только его еще сделать нужно и внедрить

Делать, я думаю не стоит, а то убьёшь пару лет Надо купить или лучше найти. Внедрение должно быть ограниченным по времени процессом.

Здравствуйте, remark, Вы писали:

E>>Ранее говорилось

Автор: remark
Дата: 03.08.06

про 100K сообщений

R>Не сообщений, а записей
R>Записи были во-первых короче среднестатистических сообщений, а во-вторых клались в неиндексированную таблицу.

И еще, наверное, в рамках bulk-операции, без фиксации транзакции после каждого инсерта.

E>>Но все равно, при необходимости записи сообщений в базу пропускная способность снижается с 40K до 10K, т.е. в четыре раза

R>Про требования пропускать через маршрутизатор 10K в секунду никто не говорил. Я имею в виду, что не БД, ни сокет вполне может не быть узким местом при требованиях в 3К. Ещё время и на обработку останется.

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

Но вообще это уже офтопик. Предлагаю завязать.

E>>Т.е. использовался датаграмный режим?

R>Нет, tcp. Но асинхронный ввод/вывод не использовался.

Да, это я забыл, что для датаграм другие примитивы используются.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, remark, Вы писали:

E>>>Ранее говорилось

Автор: remark
Дата: 03.08.06

про 100K сообщений

R>>Не сообщений, а записей
R>>Записи были во-первых короче среднестатистических сообщений, а во-вторых клались в неиндексированную таблицу.

E>И еще, наверное, в рамках bulk-операции,

Ессно

E>без фиксации транзакции после каждого инсерта.

С фиксацией

Здравствуйте, Аноним, Вы писали:

E>>Может быть вы предложите какой-нибудь несложный имитационный тест, который мы бы попытались запрограммировать в SObjectizer и замерить его производительность? А затем бы опубликовали как результаты замеров, так и исходные тексты теста.

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

Ok. Если вы сможете сформулировать подобный тест то это будет хорошим подспорьем в развитии SObjectizer.

E>>Если вы ознакомились с документацией/статьями о SObjectizer, то как вы находите их качество? Что, по вашему мнению, можно было бы улучшить?

А>Очень понравилось соотношение: "теория / описание примеров" в вашей книге "SObjectizer-4 Book".
А>Вот все б так писали

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

E>>Пока же предварительные замеры показывают следующее: на нутбуке Intel Pentium M 1.5GHz, 512Mb SObjectizer показывает пропускную способность в ~66K сообщений в секунду (под Windows XP и Visual C++ 7.1 и Slackware Linux 10.2 и GCC 3.3.2).

ANS>А что именно замерялось?

Было два основных теста. В первом создавалось N агентов и определялось M из них, которым нужно отослать сообщения. Начинался отсчет времени и первому из этих M агентов осылалось пустое сообщение. Он получал его и отсылал следующему из этого списка, тот следующему и т.д. до тех пор, пока все M агентов не отработают. Тут и фиксируется время окончания теста. Все агенты пассивные, работают на контексте одной нити. Значение N и M задаются в командной строке. Так, величина в 66K получилась при N=300000 и M=20000.

Второй тест создавал десять активных агентов -- пять sender-ов и пять receiver-ов. Каждый sender при своем старте отсылал 10K сообщений своему receiver-у. После того, как sender завершал свою работу он информировал об этом специального агента shutdowner-а. После того, как receiver получал все 10K сообщений и завершал свою работу он информировал об этом того же shutdowner-а. После того, как shutdowner получал сообщения о завершении от всех 10 агентов он останавливал SObjectizer. Фиксировалось время между стартом и остановом SObjectizer. Текст этого теста в следующем сообщении.

E>Второй тест создавал десять активных агентов -- пять sender-ов и пять receiver-ов. Каждый sender при своем старте отсылал 10K сообщений своему receiver-у. После того, как sender завершал свою работу он информировал об этом специального агента shutdowner-а. После того, как receiver получал все 10K сообщений и завершал свою работу он информировал об этом того же shutdowner-а. После того, как shutdowner получал сообщения о завершении от всех 10 агентов он останавливал SObjectizer. Фиксировалось время между стартом и остановом SObjectizer. Текст этого теста в следующем сообщении.

Вот код этого теста:

/*
    Тестирование режима блокирования ядра SObjectizer в
    функции send_msg.

    Пять активных агентов будут генерировать по 10000 сообщений,
    которые будут обрабатывать пять других активных агентов.
    Время работы теста при read-only блокировках должно
    отличаться от времени работы при read-write блокировках.
*/

#include <iostream>

#include <stdio.h>
#include <time.h>

#include <ace/OS_main.h>

#include <so_4/api/h/api.hpp>
#include <so_4/rt/h/rt.hpp>

#include <so_4/timer_thread/simple/h/pub.hpp>
#include <so_4/disp/active_obj/h/pub.hpp>

const int messages = 10000;

// Класс агента, который завершит работу теста.
class    a_shutdowner_t
    :    public so_4::rt::agent_t
{
    typedef so_4::rt::agent_t base_type_t;
    private :
        // Количество полученных msg_shutdown.
        unsigned int    m_shutdown_received;
        // Количество ожидаемых msg_shutdown.
        unsigned int    m_shutdown_awaiting;

    public :
        a_shutdowner_t(
            unsigned int shutdown_awaiting )
        :    base_type_t( "a_shutdowner" )
        ,    m_shutdown_received( 0 )
        ,    m_shutdown_awaiting( shutdown_awaiting )
        {}
        virtual ~a_shutdowner_t()
        {}

        struct    msg_shutdown {};

        virtual const char *
        so_query_type() const;

        virtual void
        so_on_subscription()
        {
            so_subscribe( "evt_shutdown", "msg_shutdown" );
        }

        void
        evt_shutdown(
            const so_4::rt::event_data_t & )
        {
            if( ++m_shutdown_received >= m_shutdown_awaiting )
                so_4::api::send_msg(
                    so_4::rt::sobjectizer_agent_name(),
                    "msg_normal_shutdown", 0 );
        }
};

SOL4_CLASS_START( a_shutdowner_t )

    SOL4_MSG_START( msg_shutdown, a_shutdowner_t::msg_shutdown )
    SOL4_MSG_FINISH()

    SOL4_EVENT( evt_shutdown )

    SOL4_STATE_START( st_normal )
        SOL4_STATE_EVENT( evt_shutdown )
    SOL4_STATE_FINISH()

SOL4_CLASS_FINISH()

// Класс тестового агента, который отсылает сообщения.
class    a_sender_t
    :    public so_4::rt::agent_t
{
    typedef so_4::rt::agent_t base_type_t;
    private :
        // Имя получателя сообщения.
        std::string    m_receiver_name;
    public :
        a_sender_t(
            const std::string & self_name,
            const std::string & receiver_name )
        :    base_type_t( self_name )
        ,    m_receiver_name( receiver_name )
        {
            so_add_traits(
                so_4::disp::active_obj::query_active_obj_traits() );
        }
        virtual ~a_sender_t()
        {}

        virtual const char *
        so_query_type() const;

        virtual void
        so_on_subscription()
        {
            so_subscribe( "evt_start",
                so_4::rt::sobjectizer_agent_name(), "msg_start" );
        }

        void
        evt_start(
            const so_4::rt::event_data_t & )
        {
            for( unsigned int i = 0; i != messages; ++i )
                so_4::api::send_msg( m_receiver_name,
                    "msg_my", 0 );
            so_4::api::send_msg( "a_shutdowner",
                "msg_shutdown", 0 );
        }
};

SOL4_CLASS_START( a_sender_t )

    SOL4_EVENT( evt_start )

    SOL4_STATE_START( st_normal )
        SOL4_STATE_EVENT( evt_start )
    SOL4_STATE_FINISH()

SOL4_CLASS_FINISH()

// Класс тестового агента, который получает сообщения.
class    a_receiver_t
    :    public so_4::rt::agent_t
{
    typedef so_4::rt::agent_t base_type_t;
    public :
        a_receiver_t(
            const std::string & self_name )
        :    base_type_t( self_name )
        ,    m_received( 0 )
        {
            so_add_traits(
                so_4::disp::active_obj::query_active_obj_traits() );
        }
        virtual ~a_receiver_t()
        {
        }

        struct    msg_my {};

        virtual const char *
        so_query_type() const;

        virtual void
        so_on_subscription()
        {
            so_subscribe( "evt_my", "msg_my" );
        }

        void
        evt_my()
        {
            ++m_received;
            if( messages == m_received )
                so_4::api::send_msg( "a_shutdowner",
                    "msg_shutdown", 0 );
        }

    private :
        // Количество полученных сообщений.
        int    m_received;
};

SOL4_CLASS_START( a_receiver_t )

    SOL4_MSG_START( msg_my, a_receiver_t::msg_my )
    SOL4_MSG_FINISH()

    SOL4_EVENT( evt_my )

    SOL4_STATE_START( st_normal )
        SOL4_STATE_EVENT( evt_my )
    SOL4_STATE_FINISH()

SOL4_CLASS_FINISH()

int
main( int, char ** )
{
    // Создаем кооперацию из 6 тестовых агентов.
    a_sender_t * a_sender_1 = new a_sender_t(
        "a_sender_1", "a_receiever_1" );
    a_sender_t * a_sender_2 = new a_sender_t(
        "a_sender_2", "a_receiever_2" );
    a_sender_t * a_sender_3 = new a_sender_t(
        "a_sender_3", "a_receiever_3" );
    a_sender_t * a_sender_4 = new a_sender_t(
        "a_sender_4", "a_receiever_4" );
    a_sender_t * a_sender_5 = new a_sender_t(
        "a_sender_5", "a_receiever_5" );
    a_receiver_t * a_receiver_1 = new a_receiver_t(
        "a_receiever_1" );
    a_receiver_t * a_receiver_2 = new a_receiver_t(
        "a_receiever_2" );
    a_receiver_t * a_receiver_3 = new a_receiver_t(
        "a_receiever_3" );
    a_receiver_t * a_receiver_4 = new a_receiver_t(
        "a_receiever_4" );
    a_receiver_t * a_receiver_5 = new a_receiver_t(
        "a_receiever_5" );
    a_shutdowner_t * a_shutdowner = new a_shutdowner_t( 10 );

    so_4::rt::agent_t * agents[] =
    {
        a_sender_1, a_sender_2, a_sender_3, a_sender_4, a_sender_5,
        a_receiver_1, a_receiver_2, a_receiver_3,
            a_receiver_4, a_receiver_5,
        a_shutdowner
    };
    so_4::rt::dyn_agent_coop_t * coop = new so_4::rt::dyn_agent_coop_t(
        "sample", agents, sizeof( agents ) / sizeof( agents[ 0 ] ) );

    clock_t finish, start = clock();
    so_4::ret_code_t rc = so_4::api::start(
        // Диспетчер будет уничтожен при выходе из start().
        so_4::disp::active_obj::create_disp(
            // Таймер будет уничтожен диспетчером.
            so_4::timer_thread::simple::create_timer_thread(),
            so_4::auto_destroy_timer ),
        so_4::auto_destroy_disp,
        coop );
    finish = clock();
    if( rc )
    {
        std::cerr << "start: " << rc << std::endl;
    }
    else
        std::cerr << "successful finish: "
            << double( finish - start ) / CLOCKS_PER_SEC
            << std::endl;

    return int( rc );
}

Здравствуйте, eao197, Вы писали:

E>>>Пока же предварительные замеры показывают следующее: на нутбуке Intel Pentium M 1.5GHz, 512Mb SObjectizer показывает пропускную способность в ~66K сообщений в секунду (под Windows XP и Visual C++ 7.1 и Slackware Linux 10.2 и GCC 3.3.2).

ANS>>А что именно замерялось?

E>Было два основных теста. В первом создавалось N агентов и определялось M из них, которым нужно отослать сообщения. Начинался отсчет времени и первому из этих M агентов осылалось пустое сообщение. Он получал его и отсылал следующему из этого списка, тот следующему и т.д. до тех пор, пока все M агентов не отработают. Тут и фиксируется время окончания теста. Все агенты пассивные, работают на контексте одной нити. Значение N и M задаются в командной строке. Так, величина в 66K получилась при N=300000 и M=20000.

Не совсем понял. 66К сообщений прошедших весь "круг" или от одного агента к другому?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

E>>Было два основных теста. В первом создавалось N агентов и определялось M из них, которым нужно отослать сообщения. Начинался отсчет времени и первому из этих M агентов осылалось пустое сообщение. Он получал его и отсылал следующему из этого списка, тот следующему и т.д. до тех пор, пока все M агентов не отработают. Тут и фиксируется время окончания теста. Все агенты пассивные, работают на контексте одной нити. Значение N и M задаются в командной строке. Так, величина в 66K получилась при N=300000 и M=20000.

ANS>Не совсем понял. 66К сообщений прошедших весь "круг" или от одного агента к другому?

Тест показывает за какое время происходит последовательная отсылка/обработка M сообщений, если в системе зарегистрировано N агентов. У меня 20000 сообщений отсылаются за ~0.3 секунды, что дает где-то около 66K в секунду (66K отсылаются за ~0.97sec). Причем этот показатель оказывается стабильным при изменении N и M в разных направлениях.

Здравствуйте, eao197, Вы писали:

ЗЫ У тебя в подписи битая ссылка: http://sobjectizer.sourceforge.org/ не открывается. Нужно http://sobjectizer.sourceforge.net/

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>ЗЫ У тебя в подписи битая ссылка: http://sobjectizer.sourceforge.org/ не открывается. Нужно http://sobjectizer.sourceforge.net/

Млин! А ведь казалось, что проверял...
Спасибо!

Возможно не все понял из статьи, но разве это не повторяет идеи библиотеки Qt, и механизмов signal->slot?
Сорри, не хватило терпения прочитать все обсуждение, может уже и есть упоминание об этом.

Здравствуйте, Аноним, Вы писали:

А>Возможно не все понял из статьи, но разве это не повторяет идеи библиотеки Qt, и механизмов signal->slot?
А>Сорри, не хватило терпения прочитать все обсуждение, может уже и есть упоминание об этом.

Спасибо за интересный вопрос, такого сравнения здесь еще не было.

Нет, не повторяет. Вы вообще-то первый, кто находит сходство между SObjectizer и механизмом signal-slot, раньше все больше сравнения с диспетчеризацией сообщений Windows выполнялось.

А различия таковы:
* синхронность signal-slot и асинхронность событий в SObjectizer. В Qt (по крайней мере в Qt3, с которой мне доводилось работать) все слоты гарантированно отрабатывали до возврата из emit-а. Для того, чтобы передать Qt-событие в другую нить на обработку требовалось создавать объект QEvent и помещать его в очередь нужной нити через postEvent (таким образом работает SObjectizer-овский диспетчер для главной нити Qt3). В SObjectizer возврат из send_msg может произойти как до обработки подписанных на сообщение событий, во время обработки или после обработки. События (т.е. экземпляры событий) автоматически размещаются в очередях нужных нитей и там обрабатываются;

* в схеме signal-slot нельзя управлять приоритетами слотов;

* в схеме signal-slot слоты никак не связаны с состоянием объекта. Если в каком-то состоянии объект не хочет, чтобы его слот вызывался, то объект сам должен делать disconnect с последующим connect-ом. В SObjectizer события явно распределены по состояниям, и если событие запрещено к обработке в текущем состоянии, то событие просто игнорируется;

* в Qt все сигналы и слоты привязаны к конкретной сигнатуре сигнала/слота. В SObjectizer эта связь менее сильная. Во-первых, в SObjectizer событие может иметь в качестве инцидентов сообщения, чей тип для события вообще не известен (экземпляр сообщения передается в событие как void *). Во-вторых, событие в SObjectizer может получить только один указатель/ссылку на объект. В Qt сигнатура сигнала/слота может содержать произвольное количество аргументов разных типов.

Ну и еще одно принципиальное различие (хотя оно больше техническое, нежели идеологическое). В Qt вспомогательный код генерируется moc компилятором почти по обычным C++ описаниям класса Qt-объекта. В SObjectizer для этого приходится вручную (пока) описывать класс агента для SObjectizer в виде специального кода на макросах (чем-то напоминающего макросные коды MFC и wxWidgets).

Здравствуйте, Евгений Охотников, Вы писали:

Наткнулся тут на такую библиотеку OSE
Судя по инфе, библиотека зародилась в 1990 и 2006 ещё выходят новые релизы.

Собственно к чему я — там есть Event Driven Systems. Может тебе будет интересно поглядеть и сравнить.
У тебя, я так понимаю, это больше фреймворк для приложений, а там больше с уклоном системного компонета.
Вот самый простенький пример оттуда:

class Agent1 : public OTC_EVAgent
 {
   public:
     Agent1() : count(0) {}
     void handle(OTC_Event* e);
   private:
     u_int count;
 };
 
 void Agent1::handle(OTC_Event* e)
 {
   if (e->type() == OTCEV_Action::typeId())
   {
     count++;
     cout << count << endl;
     if (count < 10)
     {
       e->queue(id());
       return;
     }
   }
   e->destroy();
 }
 
 main()
 {
   Agent1 a;
   OTC_Dispatcher::initialise();
   OTCEV_Action* e = new OTCEV_Action(0);
   e->queue(a.id());
   OTC_Dispatcher::run();
   return 0;
 }

Диспатчинг сообщений надо делать вручную.
Зато там есть signals, alarms, timers and i/o events в качестве источников событий. Этим перекликается с ACE_Reactor.
Т.е. нечно среднее между Агентом и клиентом Реактора...



з.ы. там ещё есть некий makeit. Может будет как-то интересно в свете mxx_ru. Там типа скриптов простеньких.

Здравствуйте, remark, Вы писали:

R>Наткнулся тут на такую библиотеку OSE

Спасибо за ссылочку.

<...>

R>Т.е. нечно среднее между Агентом и клиентом Реактора...

Мне больше показалось, что это среднее между ACE и Qt
Тем более, что солидный возраст наложил свой отпечаток на их API.

А вообще,
* как-то по счетчику загрузок не кажется, что она очень востребованна,
* Qt-ная лицензия, т.е. для закрытых проектов за нее еще и деньги платить нужно

R>з.ы. там ещё есть некий makeit. Может будет как-то интересно в свете mxx_ru. Там типа скриптов простеньких.

Ужас Очередная надстройка над GNU make в make-ровском же синтаксисе


R>

Здравствуйте, eao197, Вы писали:

E>Мне больше показалось, что это среднее между ACE и Qt
E>Тем более, что солидный возраст наложил свой отпечаток на их API.

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

E>А вообще,
E>* как-то по счетчику загрузок не кажется, что она очень востребованна,
E>* Qt-ная лицензия, т.е. для закрытых проектов за нее еще и деньги платить нужно

Ну загрузить-то можно, а лицензия на идеи не распространяется
Мне так кажется, что идеи — это самое главное, а код набить это не так долго. Сколько бы у тебя ушло сейчас "набить" SObjectizer ещё раз, если ты сейчас этим занялся? Я думаю, не очень много, да ещё бы он и лучше получился


R>>
E>

Здравствуйте, remark, Вы писали:

E>>* Qt-ная лицензия, т.е. для закрытых проектов за нее еще и деньги платить нужно

R>Ну загрузить-то можно, а лицензия на идеи не распространяется

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

R>Мне так кажется, что идеи — это самое главное, а код набить это не так долго. Сколько бы у тебя ушло сейчас "набить" SObjectizer ещё раз, если ты сейчас этим занялся? Я думаю, не очень много, да ещё бы он и лучше получился

Не факт на самом деле. Если не ошибаюсь, ядро нынешнего SObjectizer было сделано в самом начале, уже почти пять лет назад всего за месяц. Тогда просто был очень удачный период, когда все идеи уже были созревшими, код лился рекой и, что не маловажно, были понятны требования со стороны проектов, в которые планировалось его внедрить. Сейчас страшно подумать, но тогда за месяц было написано и оттестировано порядка 15-20т. строк кода.

Давно я уже не повторял таких трудовых подвигов

R>

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

Здравствуйте, Евгений Охотников, Вы писали:

А нету ли случаем для SObjectizer какого-то краткого списка поддерживаемых фич и компонентов, типа документации Doxуgen по классам. Вроде на eao197.narod.ru и sourceforge не видно. Типа как здесь.
Чего хотелось бы — хотелось бы, что бы можно было это быстро просмотреть и оценить , что есть и как оно есть, а чего нет.
Ну вот, например, по ссылке в ACE можно сразу посмотреть — "так, ACE_RW_Mutex там есть, функции TryLock() предоставляет" и т.д.
А то вот я как-то упускал из виду, что в SObjectizer есть tcp каналы с автоматическим реконнектом... может ещё что интересное упустил... хотелось бы как-то так всё это быстро окинуть взглядом, но в то же время, что бы можно было при желании заострить внимание на каких-то делалях, типа того, что в конструктор tcp канала можно передать период реконнекта и функциональность реконнекта будет автоматически включена...


Ещё такой вопрос. То, что синхронного взаимодействия "нет и нет будет", я понял... ну в принципе наверное и правильно...
А тем не менее нету ли какой-то другой поддержки паттерна запрос-ответ в фреймворке?
Понятно, что можно вручную отослать некий request_id, получатель вставит его в ответ, а потом проверять его и т.д. Но нету ли каких-то шорт-катов для поддержки такого взаимодействия?
Например, есть агент агент_читающий_настройки_из_конфигурационного_файла. К нему обращаются множество других клиентов с запросом считать такой-то параметр. А он потом отвечает другим сообщением, в котором идёт само значение параметра.
Хотелось бы, что бы как-то автоматически сматчился запрос и ответ и ответ попал только тому агенту, который отправил запрос, а не ко всем. Если ещё агенты сидят в разных потоках, то будет thundering herd problem.
Или такая задача решается как-то по другому в SObjectizer?


Ещё заодно по поводу состояний объектов. А действительно часто необходимы состояния в реальных задачах? Ты не мог бы привести какие-то более-менее реальные примеры агентов, которым действительно полезны состояния. Ну кроме коммуникационного канала, у которого есть state_connected, state_disconnected и т.д.
А то я вот думаю, может быть поддержку состояний более целессобразно отдавать самому агенту... Ну я агентов пока много не делал, поэтому самому не получается оценить...


А можно ли в рамках SObjectizer реализовать т.н. фильтры?
Под фильтрами я имею в виду следующее. Допустим есть некий агент агент_достающий_значения_из_бд. Агент отлаженный и имеющийся в качестве готового компонета. Допустим он обрабатывает сообщения do_read_value, а после считывания данных из бд отвечает сообщением on_read_value. И допустим есть уже агента-клиенты, которые пользуются этим агентом.
Я хочу добавить в систему агент_который_кэширует_значения_из_бд, причём прозрачно и для агента-сервера и для агентов-клиентов. Т.е. агент_который_кэширует_значения_из_бд регистрируется как фильтр на сообщения do_read_value, если требуемое значение есть в его кэше, то он сразу отвечает on_read_value и отменяет дальнейшую обработку сообщения, если значения в кэше нет, то он передаёт управление "дальше". Когда же идёт ответное on_read_value, то агент_который_кэширует_значения_из_бд должен его тоже перехватить и закэшировать и передать "дальше".
Имхо для систем именно компонентных и именно компонуемых из готовых компонетов, а я так понимаю, что это одно из серьёзных приемуществ агентных систем, такая функциональность была бы очень полезной...


И ещё последний момент. Раз ты этим занимался, наверное у тебя ссылочки на другие подобные агентные фреймворки... ты не мог бы что-нибудь подкинуть...
Ну вот типа как я кидал на OSE Event Driven Systems
Интересуют ссылки именно на реальные, так сказать промышленные фреймворки/библиотеки, а не теоретические ресёрчи. В принципе на любых языках, приемущественно, конечно, C++, но пойдёт и C#/Java.


Заранее благодарен...