Давно ждал новостей о C++ IDE от гениальных JetBrains. Сожалел, что не смог попасть на день открытых дверей JetBrains. А недавно наткнулся в RSS Хабра на "Видео с дня открытых дверей JetBrains", где есть видео презентации "C++ IDE и как с ней бороться":
Чтож, c нетерпением жду ReSharper с поддержкой C++ и саму С++ IDE. Жизнь в мире C++ становится все более комфортной и все менее олдскульной (Far Manager + Colorer Plugin!?).
среда, 31 июля 2013 г.
Asio samples 0.6.0 is out
Вышла очередная бета asio samples 0.6.0. Приведу здесь только основные изменения:
Остальные детали беты 0.6.0 можно прочитать в списке рассылки.
Updated
Исправление ошибок в классах ma::console_close_guard и ma::windows::console_signal_service вылилось в asio samples 0.6.1.
- Класс ma::console_controller переименован в ma::console_close_guard и реализован через boost::asio::signal_set для *nix и через ma::windows::console_signal (см. ниже) для Windows.
- Представлен класс (расширение Boost.Asio) ma::windows::console_signal (+ ma::windows::console_signal_service). Данный класс может использоваться как каркас для расширений Boost.Asio, использующих внутренние потоки. Он будет подробнее освещен в отдельной статье позже. Пока же скажу лишь, что класс ma::windows::console_signal (определен только при сборке для Windows 2000 и выше) позволяет асинхронно ожидать сигнала к закрытию консольного приложения пользователем (путем использования комбинации клавиш Ctrl+C/Ctrl+Break, закрытия окна или выхода из системы/завершения работы компьютера)
- Выделены отдельно и изменены классы ma::detail::intrusive_list и ma::detail::intrusive_slist: добавлены ссылки на конец списка, которые позволили реализовать конкатенацию списков со сложностью O(1).
- Добавлена поддержка Qt 5, Boost C++ Libraries 1.53/1.54.
Остальные детали беты 0.6.0 можно прочитать в списке рассылки.
Updated
Исправление ошибок в классах ma::console_close_guard и ma::windows::console_signal_service вылилось в asio samples 0.6.1.
понедельник, 29 октября 2012 г.
Asio samples 0.5.0 is out
Вышла очередная бета asio samples 0.5.0. Приведу здесь основные изменения, которых хватило аж на смену среднего номера версии.
Во-первых, сильно изменился (в лучшую сторону) класс
Кроме того, наконец-то, метод
При такой специализации для класса
Второе крупное нововведение заключается в поддержке проектами qt_echo_server, echo_server, async_connect и asio_performance_test_client режима io_service-per-work-thread (по аналогии с HTTP Server 2 из примеров Asio). Для CLI за этот режим отвечает параметр demux_per_work_thread. Для Windows режим io_service-per-work-thread по умолчанию отлючен (
Остальные детали беты 0.5.0 можно прочитать в списке рассылки.
Updated
Исправление ошибок и расширение поддержки лямбд вылилось в asio samples 0.5.1.
Во-первых, сильно изменился (в лучшую сторону) класс
ma::handler_storage. Теперь он поддерживает функциональные объекты с operator()(void) при специализации ma::handler_storage<void>. Кроме того, наконец-то, метод
ma::handler_storage::target() стал типизированным, что избавляет его пользователей (см. проект nmea_client) от неприятных reinterpret_cast. По умолчанию ma::handler_storage::target() возвращает void*, но теперь, при желании, этот тип можно специфицировать указав его в качестве второго шаблонного аргумента ma::handler_storage. При такой специализации для класса
ma::handler_storage_service должно быть доступно преобразование static_cast<Target*>(Handler*), где Target- специфицированный дляma::handler_storage::target()тип (т.е.Target* ma::handler_storage<Arg, Target>::target()).Handler- тип функционального объекта, хранимого вma::handler_storage.
Второе крупное нововведение заключается в поддержке проектами qt_echo_server, echo_server, async_connect и asio_performance_test_client режима io_service-per-work-thread (по аналогии с HTTP Server 2 из примеров Asio). Для CLI за этот режим отвечает параметр demux_per_work_thread. Для Windows режим io_service-per-work-thread по умолчанию отлючен (
--demux_per_work_thread=0, false, off). Для других платформ - по умолчанию включен (--demux_per_work_thread=1, true, on).Остальные детали беты 0.5.0 можно прочитать в списке рассылки.
Updated
Исправление ошибок и расширение поддержки лямбд вылилось в asio samples 0.5.1.
четверг, 19 июля 2012 г.
asio performance test
Данное сообщение будет служить для сбора всей информации, что мне удастся собрать по теме производительности Asio. Буду рад видеть в комментариях вопросы/критику/дополнения и результаты/методики тестов читателей.
Для начала выложу самое простое – отчеты профилировщика MS VS 2010. И клиент и сервер работали одновременно на моей домашней машине (причем без отключения прочих приложений вроде uTorrent и MS Outlook):
Тестирование echo_server (echo_server120719.vsps).
Тестирование asio_performance_test_client (asio_performance_test_client120719.vsps).
Буду постепенно дописывать данное сообщение. Пока выкладываю результаты как есть.
Немного поколдовал над результатами тестов: для исключения некоторых функций пришлось сделать выгрузку в Excel - echo_server120723.xls и asio_performance_test_client120723.xls (см. столбец "Elapsed Exclusive Time, fixed %").
Думал над функцией [<Unknown>] в отчете по asio_performance_test_client. Похоже, это ConnectEx - именно ее название компилятору неизвестно и именно ее вызывает функция ma::async_connect.
Updated 24.07.2012
Залил конфигурацию сборки проектов echo_server и asio_performance_test_client в SVN.
Обновил результаты тестов.
Добавил скорректированные таблицы результатов работы профилировщика в разрезе функций.
Updated 26.07.2012
Как видно из "скорректированных" таблиц результатов работы профилировщика, большую часть времени и echo_server и asio_performance_test_client проводят в системных функциях ввода-вывода (почему-то в WSASend - видимо, это связано с тем, что и сервер и клиент работали на одной и той же машине и общались через localhost) и демультиплексирования событий. По-моему, это хороший результат.
Думаю, стоит попробовать Intel VTune - интересует работа потоков.
Updated 11.08.2012
Попробовал погонять по сети и измерить VTune-ом (Core2 Duo E7200, Windows 7 x86 SP1 Pro, https://asio-samples.svn.sourceforge.net/svnroot/asio-samples/trunk@660):
Для большей наглядности почти те же данные в виде графиков:
Результаты, в общем-то, ожидаемо положительные и совпадают с отчетом "студийного" профилировщика. Единственное, что вызывает подозрение, это 2-х ядерный процессор. Я все еще ищу возможность использовать VTune на 8-ядерном процессоре (думаю, еще понадобится несколько n-ядерных машин, чтобы нагрузить такой сервер "под завязку").
Для начала выложу самое простое – отчеты профилировщика MS VS 2010. И клиент и сервер работали одновременно на моей домашней машине (причем без отключения прочих приложений вроде uTorrent и MS Outlook):
- MS Windows 7 Pro x64 SP1 + все обновления на 19.07.2012
- ASUS P6T Deluxe (LGA 1366)
- Intel Core i7 920 2.6Hz (4 physical cores), Hyper-threading on (8 logical cores)
- 12 Gb RAM 1333MHz
- Boost C++ Libraries 1.50 + все патчи из /asio_samples/build/patches/boost_1_50_0
- Qt 4.8.2 static build with static C/C++ runtime + патчи из /asio_samples/build/patches/qt_4_8_1_patches: build_static_win32-msvc2010.patch, container_msvc_warn.patch, win_cursors.patch
- Исходники asio samples из https://asio-samples.svn.sourceforge.net/svnroot/asio-samples/trunk (revision 617)
- Проект echo_server, собранный в конфигурации Profile/Win32
- Проект asio_performance_test_client, собранный в конфигурации Profile/Win32
Тестирование echo_server (echo_server120719.vsps).
- Параметры запуска echo_server (echo_server.psess):
--port=7 --inactivity_timeout=60 --session_threads=4 - Параметры запуска asio_performance_test_client:
127.0.0.1 7 4 4096 10000 600 0
Тестирование asio_performance_test_client (asio_performance_test_client120719.vsps).
- Параметры запуска asio_performance_test_client (asio_performance_test_client.psess):
127.0.0.1 7 4 4096 10000 600 0 - Параметры запуска qt_echo_server (кроме тех, чьи значения по умолчанию не менялись):
Execution/Session (IO) threads: 4; Session management/Listen backlog: 10000; Session/Inactivity timeout (seconds): 60.
Буду постепенно дописывать данное сообщение. Пока выкладываю результаты как есть.
Немного поколдовал над результатами тестов: для исключения некоторых функций пришлось сделать выгрузку в Excel - echo_server120723.xls и asio_performance_test_client120723.xls (см. столбец "Elapsed Exclusive Time, fixed %").
Думал над функцией [<Unknown>] в отчете по asio_performance_test_client. Похоже, это ConnectEx - именно ее название компилятору неизвестно и именно ее вызывает функция ma::async_connect.
Updated 24.07.2012
Залил конфигурацию сборки проектов echo_server и asio_performance_test_client в SVN.
Обновил результаты тестов.
Добавил скорректированные таблицы результатов работы профилировщика в разрезе функций.
Updated 26.07.2012
Как видно из "скорректированных" таблиц результатов работы профилировщика, большую часть времени и echo_server и asio_performance_test_client проводят в системных функциях ввода-вывода (почему-то в WSASend - видимо, это связано с тем, что и сервер и клиент работали на одной и той же машине и общались через localhost) и демультиплексирования событий. По-моему, это хороший результат.
Думаю, стоит попробовать Intel VTune - интересует работа потоков.
Updated 11.08.2012
Попробовал погонять по сети и измерить VTune-ом (Core2 Duo E7200, Windows 7 x86 SP1 Pro, https://asio-samples.svn.sourceforge.net/svnroot/asio-samples/trunk@660):
Для большей наглядности почти те же данные в виде графиков:
Результаты, в общем-то, ожидаемо положительные и совпадают с отчетом "студийного" профилировщика. Единственное, что вызывает подозрение, это 2-х ядерный процессор. Я все еще ищу возможность использовать VTune на 8-ядерном процессоре (думаю, еще понадобится несколько n-ядерных машин, чтобы нагрузить такой сервер "под завязку").
суббота, 30 июня 2012 г.
Уязвимости серверов к медленному чтению
По мотивам старой статьи на habrahabr.
Когда я писал echo_server, этой статьи на Хабре еще не было. Но я думал о том, что клиент (remote peer) может «нарочно медленно» принимать данные. Именно поэтому я использую класс ma::cyclic_buffer, совмещающий в себе и буфер приема, и буфер отправки. Благодаря такому совмещению, мне, кажется, удалось более гибко распределить ресурсы сервера:
в течение указанного для таймаута значения удаленный конец должен завершить хотя бы одну активную операцию ввода/вывода, если только таковая есть (еcли кому-то интересны подробности, спрашивайте в комментариях).
Конечно, это не полноценная защита. Но, IMHO, и сервер (middleware, application layer) надо проектировать так, чтобы минимизировать возможность проведения успешных атак (в т.ч. DOS) – в идеале вообще исключить их.
Когда я писал echo_server, этой статьи на Хабре еще не было. Но я думал о том, что клиент (remote peer) может «нарочно медленно» принимать данные. Именно поэтому я использую класс ma::cyclic_buffer, совмещающий в себе и буфер приема, и буфер отправки. Благодаря такому совмещению, мне, кажется, удалось более гибко распределить ресурсы сервера:
- с одной стороны, я выставляю ограничение памяти (размер буфера) на всю сессию,
- с другой – это ограничение динамически распределяется на буфер отправки и буфер приема одновременно, т.е. выделенное пространство используется максимально эффективно.
в течение указанного для таймаута значения удаленный конец должен завершить хотя бы одну активную операцию ввода/вывода, если только таковая есть (еcли кому-то интересны подробности, спрашивайте в комментариях).
Конечно, это не полноценная защита. Но, IMHO, и сервер (middleware, application layer) надо проектировать так, чтобы минимизировать возможность проведения успешных атак (в т.ч. DOS) – в идеале вообще исключить их.
FAQ
Соберу-ка здесь некоторые полезные материалы по теме сокетов.
Начну с правильного завершения/закрытия TCP-сессии (сокета) с точки зрения Winsock (в Linux, полагаю, можно делать аналогично, т.е. данный подход одинаково хорошо сработает и в Windows и в Linux). Немногие статьи освещают эту тему. Почему-то закрытие TCP-сессии (равно как и останов сервера) часто обделяют должным вниманием.
Кому есть что добавить - милости прошу в комментарии.
Updated 2013/12/04:
RTFM: Йон Снейдер: "Эффективное программирование TCP/IP". Очень правильная книга, вправляющая мозги по поводу многих мифов вокруг TCP. Часто встречаю в сети (форумы, списки рассылок) вопросы, решаемые прямой отсылкой к соответствующей главе данной книги.
Updated 2019/03/13:
Asio, SSL, and scalability
Updated 2020/05/23:
Why does one NGINX worker take all the load?
Начну с правильного завершения/закрытия TCP-сессии (сокета) с точки зрения Winsock (в Linux, полагаю, можно делать аналогично, т.е. данный подход одинаково хорошо сработает и в Windows и в Linux). Немногие статьи освещают эту тему. Почему-то закрытие TCP-сессии (равно как и останов сервера) часто обделяют должным вниманием.
Кому есть что добавить - милости прошу в комментарии.
Updated 2013/12/04:
RTFM: Йон Снейдер: "Эффективное программирование TCP/IP". Очень правильная книга, вправляющая мозги по поводу многих мифов вокруг TCP. Часто встречаю в сети (форумы, списки рассылок) вопросы, решаемые прямой отсылкой к соответствующей главе данной книги.
Updated 2019/03/13:
Asio, SSL, and scalability
Updated 2020/05/23:
Why does one NGINX worker take all the load?
воскресенье, 22 апреля 2012 г.
Немного новостей
Вышел очередной бета-релиз asio samples – 0.3.9.
Кроме исправления ошибок в этот релиз вошел сильно измененный Asio performance test client (проект asio_performance_test_client) из non-Boost версии Asio. Хотя данный тест, пожалуй, пригодится лишь для тестирования простейших серверов (TCP-echo/proxy), его отсутствие сильно «напрягало» – приходилось брать сторонние решения, которые работали не так, как ожидалось. Хотелось бы видеть этот тест и другие, связанные с ним, части asio samples в Boost версии Asio. Вот только с местом, куда скинуть предложение/исходники, я пока не определился – то ли на sf.net, то ли на github. Если последнее, то уместен был бы pull request, но, как я понимаю, для начала надо будет выкачать рабочую копию из своей branch, созданной на основе Asio master branch… лениво разбираться с git.
Кроме asio_performance_test_client я наконец-то довел до ума проекты для QMake – теперь есть возможность (скорее требование) указать локальную копию Boost, используемую для сборки. Для автоматической компоновки с Boost.Chrono (при наличии это библиотеки) пришлось почитать документацию к QMake :)
Не буду переписывать здесь release notes из списка рассылки asio-samples-users – добавлю лишь, что уже сегодня залил в trunk asio samples патч, заменяющий в Boost.Asio (Boost 1.49) все вызовы Win32 API InterlockedXXX на соответствующие макросы из boost/detail/interlocked.hpp. Почему автор Asio так и не перевел (см. мой вопрос в списке рассылки asio-users) Boost версию на эти макросы для меня остается загадкой (аргумент а-ля details/non-stable не принимается). Может ему просто лень настолько сильно разделять Boost и non-Boost версии?
Подписаться на:
Сообщения (Atom)