Что слышно

Интересно иногда узнать мнение более опытных разработчиков:

Parallelism Should Inspire You

Обратил внимание на:

~~~~~~~~~~~~~

IMPLICATIONS FOR COMPLEX REALTIME SYSTEMS:
Complex real-time systems would be a sea of state machine objects interacting with each other. There will be low level state machines which would work together to implement high level state machine behavior.
~~~~~~~~~~~~~

Так что подход с proactor-based active objects вполне может оказаться правильным 8)

Старт дан, что дальше?

Вот, вроде, наконец-то "пошла работа" по проекту "asio samples". Что уж и говорить, и времени не хватает и трудно "переходить" от одного приложения в "asio samples" к другому - руки так и "тянутся" что-то поправить, улучшить, добавить, но только не начинать новое приложение.


Итак, имеем (https://sourceforge.net/projects/asio-samples/):


1) nmea_client (категория "клиент") - простое чтение данных с последовательного порта с разбиением на строки. Планируется постепенно добавить "параллельный" парсинг NMEA 0183. Основная задача - показать, что разработанная модель работы с активными объектами полезна в программировании клиентов сетевых приложений и привести пример с custom memory allocation.


2) echo_server (категория "сервер") - (не)простой эхо-сервер. Планирую провести нагрузочное/стресс тестирование и сравнить с другими (может кто подскажет?).


Для начала в качестве инструмента тестирования взял tests/performance/client, что посоветовал Christopher Kohlhoff из non-boost asio 1.4.1. Но вот незадача - не умеет этот client и читать и писать одновременно (на самом деле умеет, но только за счет буферов сокета) - надо будет "прикрутить" к нему io_buffer из моего эхо-сервера, но это уже спорная модификация.


Сейчас занят следующим - ищу для тестирования эхо-сервера:


а) подходящий инструментарий - вот для Web-серверов его "навалом" я для эхо - нет (а у эхо-сервера своя специфика!)


б) другие реализации, можно даже "не-open source" - пока хочу сравнить с эхо-сервером из Windows 2003 R2 и с ProstoServer echo server - если кто может подсказать другие - "милости прошу"


в) инициативных добровольцев 8) - может кому-то интересно самому провести такое тестирование? (например, чтобы доказать, что "его/мой эхо-сервер лучше/хуже")
Очень интересно знать, какой же он - этот самый overhead от использования прослойки по имени boost::asio? Надеюсь, что в пределах 5% по сравнению с трафиком других серверов. Кроме того, надеюсь, что память будет использоваться довольно экономично (старался все таки).


Теперь о планах:


1) переделка chat_client из asio examples - "заюзаю" Qt и "свою модель работы с асинхронными активными объектами, построенными на базе boost::asio". Это будет пример того, как лучше всего (для производительности - не для простого "читателя" кода) соединять GUI и активные объекты на boost::asio (и вообще, мой первый серьезный GUI-проект с использованием Qt и boost::asio 8). Заодно "обкатаю" и Qt Creator - помимо MS VS 2008 + Qt integration) - давно интересует вопрос: как Qt Creator поведет себя на rich-template C++ code (читайте Boost C++ Libraries).


2) (естественно) переделка chat_server из asio examples - для начала по аналогии с эхо-сервером (если раньше кто-нибудь не докажет мне "провальность" моего старания) - но основная задача переделки - подготовка к усложнению протокола, предложенного в asio examples для chat-а: переделка будет в несколько этапов и на первом из них планирую ввести handshake, authentication (login), logout (с возможностью последующего login), shutdown, timeouts (connect, login, read-write, inactivity).


Вот еще вчера Christopher Kohlhoff наконец-то "всенародно признался" (asio-users mailing list), что SSL в boost::asio не поддерживает custom memory allocation (не случайно я всегда смотрю код перед тем как на него положиться!) - думаю SSL - это minimum must have в любом сервере - так что надо попробовать осилить OpenSSL и переделать boost::asio::ssl::detail::openssl_stream_service - но прежде надо четко все распланировать и "вставить" это в общий план.