Дмитрий Дагаев. Реализация однопоточного коммуникационного ПО
Статья в сборнике трудов конференции "Объектные системы-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.