Дмитрий Дагаев. Реализация однопоточного коммуникационного ПО
Статья в сборнике трудов конференции "Объектные системы-2013".
http://objectsystems.ru/files/2013/Obje ... edings.pdf
Цитата: При модернизации распределенной системы обработки данных АСУТП АЭС была
поставлена задача замены коммуникационного ПО. Рассматривались действующее ПО на
основе CORBA [1], реализующее клиент-серверное взаимодействие, технология DDS [2] на
основе модели публикация-подписка и новая разработка ПО для этих задач. При этом нужно
было повысить качество сетевого взаимодействия.
Действующая система была реализована в виде многопоточного пользовательского ПО
с блокировками потоков до получения данных. При сбоях связи и зависаниях сети система
штатно переходила на резервированные сети, с выдерживанием задержек, но время от
времени приходилось сталкиваться с присущими CORBA проблемами [3]: "ошибками,
относящимися к надежности потоков управления, надежности исключительных ситуаций и
управлению памятью". Опыт эксплуатации показывал не всегда правильное
функционирование при сложных условиях связи, ошибках в сети и переходах на резервные
маршруты передачи данных. Кроме того, архитектурно сложно выглядели системы,
требующие модели публикации-подписки.
Второй подход, в свою очередь, не слишком хорошо решает не присущие DDS клиент-
серверные задачи. Предлагаемый [2] протокол RTPS использует UDP как транспортный
уровень и переносит механизмы гарантированной доставки на пользовательский уровень.
Это не первый и не последний способ реализации функциональности TCP в пространстве
пользователя. Является ли это решение не худшим, чем транспортная реализация TCP, - это
вопрос, требующий тщательного рассмотрения.
С точки зрения приложения важен еще момент буферизации данных, которые
получены по UDP. DDS предоставляет многопоточные сетевые сервисы для этих целей,
которые добавляют еще один уровень сложности.
Учитывая вышесказанное, было принято решение разработки коммуникационного ПО
TA (англ. Transparent Architecture), призванного совместить клиент-серверную модель и
модель публикации-подписки. Технология Transparent Architecture построена на основном
временном цикле одного потока, который осуществляет прием и передачу данных без
единой блокировки. Это, кстати, дает дополнительное преимущество, т.к. "все переключения
контекста при получении каждого пакета сильно расходуют время центрального процессора
и существенно снижают производительность сети" [4] .
Цитата: 1. Основные принципы реализации
Неблокируемость и немодальность – ключевые особенности Transparent Architecture.
Клиентские программы в клиент-серверных приложениях часто построены по принципу
выделения отдельного потока для приема данных от сервера. Типичными особенностями
такой схемы является модальность, заключающаяся в переходе в режим ожидание чтения
данных с таймаутом. Поток при этом блокируется, при обрыве связи происходят переходы
от одного таймаута к другому.
Транспортный уровень построен на неблокирующих способах взаимодействия (в
частности, сокетах). Прием данных осуществляется при наличии данных без ожидания,
передача – без ожидания завершения, которое будет зафиксировано позднее. Главный цикл
обеспечивает точность поддержания времени в соответствии с требованиями задачи и
возможностями операционной системы.
Цитата: Первоначально коммуникационное ПО было реализовано в виде C-библиотеки с возможностью присоединения к BlackBox. Начиная с версии 2.0, появились Оберон- реализации для BlackBox и XDS. Все реализации тестировались для ОС Windows и Linux. TA реализована, версия 2.0 доступна в исходных текстах как ta1 на sourceforge.net. http://sourceforge.net/projects/ta1/ |
