Научная статья на тему 'Реализация управляемой приложением функциональной архитектуры пиринговой распределенной вычислительной системы, определяемой концептуальными и логическими моделями искусственного интеллекта. II. Декларативноимперативный и логико-алгебраический подходы'

Реализация управляемой приложением функциональной архитектуры пиринговой распределенной вычислительной системы, определяемой концептуальными и логическими моделями искусственного интеллекта. II. Декларативноимперативный и логико-алгебраический подходы Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
0
0
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
распределенные вычислительные системы / P2P-вычисления / функциональная архитектура / технологии локальных и глобальных сетей / гибридные P2P-сети / декларативно-императивная модель / концептуальная логическая сеть Петри / формализация декларативно-императивной и логико-алгебраический модели распределенных вычислений / distributed computing systems / P2P computing / functional architecture / local and global network technologies / hybrid P2P networks / declarative-imperative model / conceptual logical Petri net / formalization of declarative-imperative and logical-algebraic models of distributed computing

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Владимир Иванович Волчихин, Надежда Сергеевна Карамышева, Максим Александрович Митрохин, Сергей Александрович Зинкин

Актуальность и цели. В настоящее время ведутся интенсивные поиски решений в области создания инфраструктуры для сетевых приложений, например для децентрализованного Интернета на основе нескольких основных технологий: блокчейна, машинного обучения, Семантической паутины и Интернета вещей. Рассматривается возможность организации инфраструктуры децентрализованного Интернета (Distributed Web – DWeb) в виде одноранговой P2P-сети (peer-to-peer), узлами которой являются устройства пользователей. Целью настоящей работы является исследование одного из подходов к практической реализации управляемой приложением функциональной архитектуры сетевой распределенной вычислительной системы (РВС) ADFA-DCS (Application-Driven Functional Architecture of Distributed Computing System), определяемой концептуальными и логическими моделями искусственного интеллекта. Материалы и методы. Предложена новая функциональная архитектура РВС, определяемая приложением, реализация которой отличается от известных тем, что работа приложения предварительно определяется исполнимой моделью – концептуальным графом сети Петри. Затем формируется структура, задающая логику работы приложения, и на ее основе генерируется распределенная управляющая программа. Этот принцип позволяет реализовывать произвольные распределенные алгоритмы без существенных затрат на перепрограммирование приложения. Результаты. Предложенная функциональная архитектура реализуется на платформе глобальной или локальной вычислительной сети, на которой определена логическая системная архитектура РВС. Для реализации системной архитектуры рассматриваемых РВС выбраны технологии, близкие к пиринговой технологии Р2Р. Авторы настоящей работы полагают, что концепция РВС с предложенной архитектурой хорошо согласуется с платформой территориально-распределенных корпоративных сетей SD-WAN (Software Defined Wide Area Network), при построении которых реализован принципиально новый подход к управлению сетью. Выводы. Разработана технология создания функциональной архитектуры РВС, управляемой приложением, которая согласована с технологиями пиринговых и программно-определяемых сетевых технологий. Процесс программирования распределенного приложения сопровождается использованием функций передачи сообщений и данных, поиском данных в таблицах, копии которых находятся на всех узлах P2P-сети и реализацией операторов, выполняющих функции, для которых и была предназначена создаваемая сетевая РВС.

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Владимир Иванович Волчихин, Надежда Сергеевна Карамышева, Максим Александрович Митрохин, Сергей Александрович Зинкин

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

The implementation of an application-driven functional architecture of a peer-to-peer distributed computing system defined by conceptual and logical models of artificial intelligence. II. The declarative-imperative and logical-algebraic approaches

Background. Currently, there is an intensive search for solutions in the field of creating infrastructure for network applications, for example, for the decentralized Internet based on several main technologies: blockchain, machine learning, Semantic Web and Internet of Things. The possibility of organizing the infrastructure of the decentralized Internet, or Distributed Web – DWeb, in the form of a peer-to-peer (P2P) network, the nodes of which are user devices, is being considered. The aim of this work is to study one of the approaches to the practical implementation of the application-driven functional architecture of the ADFA-DCS (Application-Driven Functional Architecture of Distributed Computing System), defined by conceptual and logical artificial intelligence models. Materials and methods. A new functional architecture of the DCS is proposed, which is determined by the application, the implementation of which differs from the known ones in that the operation of the application is preliminarily determined by the executable model – the conceptual Petri net graph. Then a structure is formed that specifies the logic of the application, and on its basis a distributed control program is generated. This principle makes it possible to implement arbitrary distributed algorithms without significant costs for reprogramming the application. The authors of this work believe that the concept of a distributed network with the proposed architecture is in good agreement with the platform of geographically distributed corporate networks SD-WAN (Software Defined Wide Area Network), the construction of which implements a fundamentally new approach to network management. Results. The proposed functional architecture is implemented on a global (WAN) or local area network platform (LAN), on which the logical system architecture of a distributed computing system is defined. To implement the system architecture of the DCS under consideration, technologies close to peer-to-peer technology were selected. The process of programming a distributed application is accompanied by the use of message and data transfer functions, searching for data in tables, copies of which are located on all nodes of the P2P network, and the implementation of operators performing functions for which the created network DCS was intended.

Текст научной работы на тему «Реализация управляемой приложением функциональной архитектуры пиринговой распределенной вычислительной системы, определяемой концептуальными и логическими моделями искусственного интеллекта. II. Декларативноимперативный и логико-алгебраический подходы»

ИНФОРМАТИКА, ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА И УПРАВЛЕНИЕ

COMPUTER SCIENCE, COMPUTER ENGINEERING AND CONTROL

УДК 004.9

doi: 10.21685/2072-3059-2024-2-1

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

В. И. Волчихин1, Н. С. Карамышева2, М. А. Митрохин3, С. А. Зинкин4

12.34Пензенский государственный университет, Пенза, Россия 1cnit@pnzgu.ru, 2karamyshevans@yandex.ru, 3vt@pnzgu.ru, 4zsa49@yandex.ru

Аннотация. Актуальность и цели. В настоящее время ведутся интенсивные поиски решений в области создания инфраструктуры для сетевых приложений, например для децентрализованного Интернета на основе нескольких основных технологий: блок-чейна, машинного обучения, Семантической паутины и Интернета вещей. Рассматривается возможность организации инфраструктуры децентрализованного Интернета (Distributed Web - DWeb) в виде одноранговой Р2Р-сети (peer-to-peer), узлами которой являются устройства пользователей. Целью настоящей работы является исследование одного из подходов к практической реализации управляемой приложением функциональной архитектуры сетевой распределенной вычислительной системы (РВС) ADFA-DCS (Application-Driven Functional Architecture of Distributed Computing System), определяемой концептуальными и логическими моделями искусственного интеллекта. Материалы и методы. Предложена новая функциональная архитектура РВС, определяемая приложением, реализация которой отличается от известных тем, что работа приложения предварительно определяется исполнимой моделью - концептуальным графом сети Петри. Затем формируется структура, задающая логику работы приложения, и на ее основе генерируется распределенная управляющая программа. Этот принцип позволяет реализовывать произвольные распределенные алгоритмы без существенных затрат на перепрограммирование приложения. Результаты. Предложенная функциональная архитектура реализуется на платформе глобальной или локальной вычислительной сети, на которой определена логическая системная архитектура РВС. Для реализации системной архитектуры рассматриваемых РВС выбраны технологии, близкие к пиринговой технологии Р2Р. Авторы настоящей работы полагают, что концепция РВС с предложенной архитектурой хорошо согласуется с платформой территориально-распределенных корпоративных сетей SD-WAN

© Волчихин В. И., Карамышева Н. С., Митрохин М. А., Зинкин С. А., 2024. Контент доступен по лицензии Creative Commons Attribution 4.0 License / This work is licensed under a Creative Commons Attribution 4.0 License.

(Software Defined Wide Area Network), при построении которых реализован принципиально новый подход к управлению сетью. Выводы. Разработана технология создания функциональной архитектуры РВС, управляемой приложением, которая согласована с технологиями пиринговых и программно-определяемых сетевых технологий. Процесс программирования распределенного приложения сопровождается использованием функций передачи сообщений и данных, поиском данных в таблицах, копии которых находятся на всех узлах Р2Р-сети и реализацией операторов, выполняющих функции, для которых и была предназначена создаваемая сетевая РВС. Ключевые слова: распределенные вычислительные системы, Р2Р-вычисления, функциональная архитектура, технологии локальных и глобальных сетей, гибридные Р2Р-сети, декларативно-императивная модель, концептуальная логическая сеть Петри, формализация декларативно-императивной и логико-алгебраический модели распределенных вычислений

Для цитирования: Волчихин В. И., Карамышева Н. С., Митрохин М. А., Зинкин С. А. Реализация управляемой приложением функциональной архитектуры пиринговой распределенной вычислительной системы, определяемой концептуальными и логическими моделями искусственного интеллекта. II. Декларативно-императивный и логико-алгебраический подходы // Известия высших учебных заведений. Поволжский регион. Технические науки. 2024. № 2. С. 5-31. doi: 10.21685/2072-3059-2024-2-1

The implementation of an application-driven functional architecture of a peer-to-peer distributed computing system defined by conceptual and logical models of artificial intelligence. II. The declarative-imperative and logical-algebraic approaches

V.I. Volchikhin1, N.S. Karamysheva2, M.A. Mitrokhin3, S.A. Zinkin4

i,2,3,4penza State University, Penza, Russia 1cnit@pnzgu.ru, 2karamyshevans@yandex.ru, 3vt@pnzgu.ru, 4zsa49@yandex.ru

Abstract. Background. Currently, there is an intensive search for solutions in the field of creating infrastructure for network applications, for example, for the decentralized Internet based on several main technologies: blockchain, machine learning, Semantic Web and Internet of Things. The possibility of organizing the infrastructure of the decentralized Internet, or Distributed Web - DWeb, in the form of a peer-to-peer (P2P) network, the nodes of which are user devices, is being considered. The aim of this work is to study one of the approaches to the practical implementation of the application-driven functional architecture of the ADFA-DCS (Application-Driven Functional Architecture of Distributed Computing System), defined by conceptual and logical artificial intelligence models. Materials and methods. A new functional architecture of the DCS is proposed, which is determined by the application, the implementation of which differs from the known ones in that the operation of the application is preliminarily determined by the executable model - the conceptual Petri net graph. Then a structure is formed that specifies the logic of the application, and on its basis a distributed control program is generated. This principle makes it possible to implement arbitrary distributed algorithms without significant costs for reprogramming the application. The authors of this work believe that the concept of a distributed network with the proposed architecture is in good agreement with the platform of geographically distributed corporate networks SD-WAN (Software Defined Wide Area Network), the construction of which implements a fundamentally new approach to network management. Results. The proposed functional architecture is implemented on a global (WAN) or local area network platform (LAN), on which the logical system architecture of a distributed computing

system is defined. To implement the system architecture of the DCS under consideration, technologies close to peer-to-peer technology were selected. The process of programming a distributed application is accompanied by the use of message and data transfer functions, searching for data in tables, copies of which are located on all nodes of the P2P network, and the implementation of operators performing functions for which the created network DCS was intended.

Keywords: distributed computing systems, P2P computing, functional architecture, local and global network technologies, hybrid P2P networks, declarative-imperative model, conceptual logical Petri net, formalization of declarative-imperative and logical-algebraic models of distributed computing

For citation: Volchikhin V.I., Karamysheva N.S., Mitrokhin M.A., Zinkin S.A. The implementation of an application-driven functional architecture of a peer-to-peer distributed computing system defined by conceptual and logical models of artificial intelligence. II. The declarative-imperative and logical-algebraic approaches. Izvestiya vysshikh uchebnykh zavedeniy. Povolzhskiy region. Tekhnicheskie nauki = University proceedings. Volga region. Engineering sciences. 2024;(2):5-31. (In Russ.). doi: 10.21685/2072-30592024-2-1

Введение

Распределенные вычислительные системы (РВС) появились как результат развития новых технологий, направленных на реализацию удаленного доступа пользователей к удаленным вычислительным ресурсам. Получили развитие архитектуры типа «клиент-сервер» и «мастер-исполнитель», а собственно сложные в алгоритмическом плане и в плане использования вычислительных ресурсов вычисления реализуются в удаленных кластерных и мощных массивно-параллельных системах, в рамках архитектуры грид-систем (англ. grid - сетка, решетка) [1-3]. Многими специалистами получены решения фундаментальных проблем, связанных с архитектурой грид-вычис-лений в открытых средах. На основе концепции грид-вычислений предложен, но до конца не реализован, ряд новых самонастраивающихся, адаптивных и развивающихся архитектур.

Пиринговые, или peer-to-peer (P2P), вычисления, стали, в числе других моделей, распространенным вариантом реализации крупномасштабных распределенных вычислений [4-6]. Распределенные вычислительные системы на базе Р2Р-сетей способны поддерживать декомпозиции задач и взаимодействие между задачами. В отличие от архитектуры типа «клиент-сервер» и родственной ей архитектуры «мастер-исполнитель», такая организация вычислений позволяет сохранять работоспособность сети при любом количестве и любом сочетании доступных узлов.

Проведенный анализ известных публикаций в области создания РВС показывает, что описания известных решений касаются в основном системной архитектуры и внутреннего управления функционированием инфраструктуры на промежуточном (middleware) уровне. Алгоритмические проблемы, возникающие на прикладном уровне, равно как и реализация распределенных приложений в распределенной вычислительной среде, в литературе описана недостаточно. Обычно пользователю предоставляются готовые сервисы, реализованные в Р2Р-среде. Однако эта среда может использоваться и для создания пользовательских сетевых приложений, которые фактически задают функциональную архитектуру РВС.

Представляет большой интерес известная технология SD-WAN (англ. Software-Driven Wide Area Network) [7, 8] обладающая рядом преимуществ, которые, как предполагают многие специалисты, в перспективе будут востребованы в большинстве современных сетей. Появляющиеся приложения и рабочие сценарии предъявляют строгие требования к передаче данных на большие расстояния, заставляя сетевых операторов проектировать глобальные сети с новой точки зрения. Программно-определяемая глобальная сеть, т.е. SD-WAN, считается многообещающей архитектурой глобальных сетей следующего поколения. Отметим, что реализация основных стратегий маршрутизации важна и в так называемых неструктурированных Р2Р-сетях для последующего эффективного поиска и обмена данными. Остается актуальным решение следующих задач: выбор наилучшей стратегии планирования и управления ресурсами; обеспечение совместимости и взаимодействия пиринговых узлов. Частично эти задачи можно решать путем использования технологии программно-определяемых распределенных сетей SD-WAN, которые специально предназначены для управления сетью и передачи данных между центром и периферией. Функция центра, не являющегося сервером, не противоречит идее пиринговых вычислений, тем более, что во многих Р2Р-сетях центральный узел обеспечивает координацию работы равноправных узлов и управление безопасностью сети. Сети SD-WAN обеспечивают интеллектуальное управление трафиком, который передается от центра к периферии и обратно; для этих сетей характерна также единая точка управления и мониторинга всей инфраструктуры.

Возможны различные технологии разработки приложений подобного вида, из которых наиболее близкими являются технологии на основе какого-либо агентно-ориентированного фреймворка, например JADE (англ. Java Agent DEvelopment Framework) [9, 10], и технологии волонтерских вычислений VC (англ. Volunteer Computing), положенные в основу создания программного комплекса BOINC (англ. Berkeley Open Infrastructure for Network Computing) [11, 12]. Волонтерские вычисления основаны на использовании пользовательских компьютеров и позволяют выполнять большой объем вычислительных работ. Платформа BOINC (широко используемая система промежуточного программного обеспечения с открытым исходным кодом) позволяет избавиться от многих недостатков, присущих волонтерским вычислениям и связанных с их ненадежностью, неоднородностью и переменным составом ресурсов.

В проектах, основанных на волонтерских вычислениях, активно участвуют около 700 тыс. устройств. Эти устройства имеют около 4 млн процессорных ядер и 560 тыс. графических процессоров, в совокупности обеспечивая среднюю пропускную способность 93 петафлопс. Устройства представляют собой в основном современные компьютеры высокого класса: их средняя производительность составляет 16,5 гигафлопс процессора, а емкость оперативной памяти - 11,4 гигабайт; большинство из них имеют графические процессоры, способные выполнять вычисления общего назначения с использованием OpenCL или CUD A [12].

Другой крупный проект - Worldwide LHC Computing Grid, WLCG (англ. Worldwide LHC Large Hadron Collider Computing Grid) [13], реализуется на основе глобального сотрудничества около 170 вычислительных цен-

тров, объединяющих национальные и международные грид-инфраструктуры, расположенные в более чем 40 странах. WLCG объединяет глобальные вычислительные ресурсы для хранения, распространения и анализа примерно 200 петабайт данных, ожидаемых каждый год от работы Большого адронного коллайдера (БАК) в ЦЕРНе - Европейском центре ядерных исследований (CERN - The European Center for Nuclear Research), крупнейшем в мире исследовательском центре физики элементарных частиц.

Несмотря на огромные вычислительные мощности компьютеров в приведенных в качестве примеров вычислительных платформах, их архитектура практически не приспособлена для реализации концепции, выраженной слоганом фирмы SUN Microsystems (ныне в составе фирмы Oracle) "The network is the computer" ("Сеть - это компьютер"). Некоторые информационно-коммуникационные инфраструктуры, поддерживающие эту концепцию, первоначально были рассмотрены в работе [14].

Описываемый в настоящей работе проект сохраняет преемственность по отношению к проектам РВС, реализации которых выполнены на платформе JADE для мультиагентных систем [15-18], отличаясь от данных работ платформой и методом формирования функциональной архитектуры.

1. Декларативно-императивный и логико-алгебраический подходы к синтезу функциональной архитектуры РВС на платформе Р2Р-сети

Концепция управляемой приложением функциональной архитектуры распределенной сетевой вычислительной системы

В настоящей работе поставлена задача реализации управляемой приложением функциональной архитектуры распределенной сетевой вычислительной системы ADFA-DCS (англ. Application-Driven Functional Architecture of Distributed Computing System), позволяющей реализовать схему взаимодействия компьютеров при выполнении распределенных вычислений согласно концептуальному графу распределенного приложения. Приложение должно решать такие задачи, как реализация любой схемы взаимодействия удаленных узлов между собой и возможность выполнения определенной задачи на конкретном узле. Реализация таким образом определенной архитектуры затрагивает прикладной (application), промежуточный (middleware) и транспортный (transport) уровни Р2Р-сети. Начальное описание технологии ADFA-DCS было дано в работе [19].

Сходство технологий ADFA-DCS и SD-WAN основано на том, что они обе реализуются в компьютерных сетях и, естественно, могут быть интегрированы. Однако функциональная архитектура РВС, создаваемая на основе технологии ADFA, предназначена не для решения проблем, связанных с маршрутизацией, балансировкой нагрузки и поддержки политик безопасности для всей сети, т.е. не для организации эффективного управления сетью, а для поддержки технологии прикладного (application) распределенного программирования в сетевой среде, обеспечивающего хранение и обработку данных на пиринговых узлах и задействующего при выполнении одного и того же приложения множество узлов на основе механизма передачи сообщений (англ. Message PassingMechanism).

Поддержка технологии ADFA-DCS может осуществляться как на прикладном уровне при возможном доступе к некоторым протоколам транспорт-

ного уровня, так и на уровне промежуточного программного обеспечения (middleware).

Существенным отличием предлагаемого подхода от известных является использование технологии непосредственной реализации распределенного алгоритма в форме промежуточного сетевого программного обеспечения MOM (англ. Message-Oriented Middleware), т.е. обеспечения слоя, ориентированного на обработку сообщений и занимающего подуровень AD MOM - Application-Driven Message-Oriented Middleware, возможно, непосредственно над подуровнем SD-WAN Middleware. За отправную точку принята реализация функциональной архитектуры РВС, задаваемой приложением (англ. Application-Driven Functional Architecture). Системная архитектура РВС реализуется на платформе произвольной глобальной или локальной компьютерной сети, например, на базе TCP/IP сети.

Определение процедурной составляющей модели представления знаний о функционировании РВС

Концепция использования декларативного подхода к созданию функциональной архитектуры, т.е. системного программного обеспечения (ПО) РВС на уровне middleware, была предложена в работе [19]. Недостатком подобного подхода является то, что проектирование основано на использовании фактов, полученных на основе анализа концептуального графа (КГ) распределенного алгоритма. Правила реализуются на основе анализа фактов непосредственно при составлении программы. Процедурная составляющая модели представления знаний, такой как КГ, выражена неявно, и полученные факты трудно использовать при программировании распределенного приложения, поскольку правила вывода придется составлять вручную, используя предикаты следования. В настоящей работе предложено использовать подход, основанный на применении интегрированной модели представления знаний -концептуальной логической сети Петри (КЛ СП), в которой явно представлены как декларативная, так и процедурная части [20, 21]. На рис. 1 представлена КЛ СП, построенная на основе КГ для распределенного алгоритма.

Здесь процедурная составляющая модели представления знаний задана явно при помощи переходов сети Петри, «встроенных» непосредственно в концептуальный граф.

Операторы-позиции A0, Ai, ..., Ai4 представлены концептами. Аналогично концептами представлены пиринговые узлы Yo, Yi, ..., Y8.

В графе Gi ромбами представлены переходы To, Ti, ..., Tw, имена которых начитаются с буквы T; имя T&& означает, что на входе и выходе перехода реализуется конъюнктивная логика, T** - что на входе и выходе реализуется дизъюнктивная логика. Предполагается, что вычисление значения 1, 2 или 3 параметра k (что соответствует истинности одного из условий а1, а2 или аз) осуществляется при выполнении оператора A9. Имя D используется для обозначения отношения развертывания операторов распределенного алгоритма по узлам Р2Р-сети. Унарный предикат R задает начальную разметку КЛ СП, а именно оператора-позиции Ao.

Интеллектуальный редактор концептуальных графов позволяет автоматически получить не только факты, но и правила срабатывания переходов КЛ СП. Факты и правила позволяют сформировать содержимое конфигурационного файла сетевого приложения (табл. 1).

Рис. 1. Концептуальная логическая сеть Петри для распределенного приложения, реализуемого в Р2Р-сети (граф 0\)

Таблица 1

Факты, правила и содержимое конфигурационного файла

Facts Факты Rules Правила Содержимое конфигурационного файла сетевого приложения

an AO is the R

a YO s the D of an AO; an AO results from T1O of an A14; AO; YO A14; A1

a YO s the D of an A1; an A1 results from TO of an AO; A1; YO AO; A2

a YO s the D of an A2; an A2 results from T1 of an A1; A2; YO A1; A3 / A4 / A5

a Y1 s the D of an A3; an A3 and an A4 and an A5 results from T2&& of an A2; A3; Y1 A2; A6

a Y2 s the D of an A4; A4; Y2 A2; A6

a Y3 s the D of an A5; A5; Y3 A2; A6

a Y3 s the D of an A6; an A6 results from T3&& of an A3 and an A4 and an A5; A6; Y3 A3 / A4 / A5; A7

a Y4 s the D of an A7; an A7 results from T4 of an A6; A7; Y4 A6; A8

a Y4 s the D of an A8; an A8 results from T5 of an A7; A8; Y4 A7; A9

a Y4 s the D of an A9; an A9 results from T6 of an A8; A9; Y4 A8; A1O, A11, A12

a Y5 s the D of an A1O an A1O or an A11 or an A12 results from T7** of an A9; A1O; Y5; A9; A13

a Y6 s the D of an A11 A11; Y6; A9; A13

a Y7 s the D of an A12 A12;Y7;A9;A13

a Y8 s the D of an A13 an A13 results from T8** of an A1O or an A1O or an A12; A13; Y8; A1O, A11, A12; A14

a Y8 s the D of an A14; an A14 results from T9 of an A13; A14; Y8; A13; AO

Для хранения текстового представления концептуального графа в приложении выбран текстовый файл. Приложение способно реализовывать произвольные схемы взаимодействия узлов сети; для изменения схемы взаимодействия достаточно изменить конфигурационный файл [19]. Данные формируются и записываются в файл по следующей схеме:

"[Оператор] ; [Узел] ; [Родительские операторы] ; [Дочерние операторы]".

В случае отсутствия родительских или дочерних операторов допускается ничего не указывать на месте соответствующих полей, тогда формат записи данных имеет следующий вид: "Д0; УС; ;".

Пропуск полей оператора и узла не допускается.

2. Формализация декларативно-императивной

и логико-алгебраической модели распределенных вычислений

Формализованные сетевые спецификации Х1 для пиринговой сети с равноправными участниками

На основании КЛ СП G1 (см. рис. 1 и табл. 1) получена следующая система Х1 продукционных правил, составленная с использованием логики предикатов первого порядка (здесь и далее символы операторов A заменены на символы позиций P с сохранением индексов).

Система Х1:

To: Start & R(Po) & - R(P0 — - R(Po) & R(P0;

T1: R(P0 & - R(P2) — - R(P1) & R(P2); T2&& : R(P2) & - R(P3) & - R(P4) & - R(P5) — — - R(P2) & R(P3) & R(P4) & R(P5); T3&& : R(P3) & R(P4)& R(P5)& - R(P6) —

—^ —I R(P3) & R(P4)& R(P5)& R(P6).

T4: R(P6) & - R(Pt) — - R(P6) & R(P?);

T5: R(Pt) & - R(P8) — - R(Pt) & R(P8);

T6: R(P8) & - R(P9) — - R(P8) & R(P9); T7**: R(P9) & - R(P1o) & - R(Pu) & - R(P12) — — - R(P9) & (аю & R(P1o) V а11 & R(Pn) v а12 & R(P12)); T8**: (аю & R(P1o) & - R(P13) — R(P13) & - R(P1o)) v v (ап& R(Pn) & - R(P13) — R(P13) & - R(Pn)) v v (а12 & R(P12) & - R(P13) — R(P13) & - R(P12));

T9: R(P13) & - R(P14) — - R(P13) & R(P14);

T1o: R(P14) & - R(Po) — - R(P14) & R(Po).

Символ импликации разделяет антецедент-посылку (слева) и кон-секвент-следствие (справа) в продукционных правилах. Фактически данная система продукционных правил доопределяет функциональную архитектуру РВС, реализация которой рассмотрена в работе [19]. Условно систему £1 продукционных правил можно отнести к исполнимым моделям в том смысле, что она может быть основой при программировании сетевого приложения для РВС. Однако такая система остается сложной при программировании, так как требуется учесть многие неформализованные особенности сетевого программирования. Поэтому при рассмотрении следующего примера уделено особое внимание уделяется представлению сетевых команд в рамках формализованных спецификаций.

Формализованные сетевые спецификации для пиринговой сети с равноправными участниками и выделенным узлом-диспетчером

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

Рис. 2. Логическая системная архитектура централизованной пиринговой сети с равноправными участниками и выделенным узлом-диспетчером

Концептуальная логическая сеть Петри для распределенного приложения, реализуемого в Р2Р-сети с центральным коммутатором - диспетчером узлов Comm (граф G2), представлена на рис. 3.

Рис. 3. Концептуальная логическая сеть Петри для распределенного приложения, реализуемого в Р2Р-сети с центральным коммутатором -диспетчером узлов Сотт (граф 02)

Работа сети начинается со срабатывания актора-перехода Ts. Унарный предикат R задает начальную разметку позиции Start. Далее сообщения перемещаются по сети в соответствием с распределенным алгоритмом. Узлы Yo, Yi, ..., Y8 в Р2Р-сети равнодоступны друг другу через диспетчер узлов Comm. На узлах размещены модули-задачи Ao, Ai, ..., Am, которые при описании концептуального графа называются операторами-концептами. Бинарный предикат Exec связывает позиции P0, P1, ..., P15 c операторами-концептами. Бинарный предикат Place связывает позиции с узлами сети, на которых они расположены.

Акторы-переходы To, Ti, ..., T15 реализуются программно. Размещение модулей-задач и программ акторов-переходов To, Ti, ..., T15 учитывается при реализации распределенного приложения. Число узлов и программных модулей соответствует распределенному приложению, которое реализовано реально и рассмотрено в качестве примера. При дальнейшем описании КЛ СП, как это нередко делается, используется отождествление объектов РВС и распределенного приложения с самой моделью.

Акторы-переходы и позиции в графе G2 задают императивную, или процедурную, составляющую модели представления знаний о работе РВС. Правила срабатывания акторов-переходов реализуются программно в соответствии с логико-алгебраическими операционными выражениями (ЛАОВ). Эти выражения построены на основании системы продукционных правил и являются декларативно-императивной моделью представления знаний о функционировании РВС. В графе G2 на рис. 3 не учтено наличие в РВС узла-диспетчера Comm, чтобы не загромождать рисунок. Наличие узла-диспетчера будет учтено непосредственно в системе ЛАОВ £2.

Система £2:

Ts/Po: [R*(Start)] (R*(Po) ^ true © E);

To/Po: [R(Po)](Exec(Po, Ao) ^ Da0, [Q**(PCom)]{E}(Msg(Po, Paom) ^ Da0, Ack*(PCom, Po) ^ true, Msg(PCom, Pi) ^ Da0, R*(Pi) ^ true, Ack*(Pi, PCom) ^ true), Q**(PCom) ^ false, R(Po) ^ - R(Po) © E);

T1/P1: [R(Pi)](Exec(Pi, Ai) ^ Da1, [Q**(PCom)]{E}(Msg(Pi, PCom) ^ Da1, Ack*(PCom, Pi) ^ true, Msg(PCom, P2) ^ Da1, R*(P2) ^ true, Ack*(P2, PCom) ^ true), Q**(PCom) ^ false, R(Pi) ^ - R(Pi) © E);

T2/P2: [R(P2)](Exec(P2, A2) ^ Da2, ([Q**(PCom)]{E}(Msg(P2, PCom) ^ Da2, Ack*(PCom, P2) ^ true, Msg(PCom, P3) ^ Da2, R*(P3) ^ true,

Ack*(P3, PCom) ^ true, Q**(PCom) ^ false)), ([Q**(PCom)]{E}(Msg(P2, PCom,) ^ Da2, Ack*(PCom, P2) ^ true, Msg(PCom, P4) ^ Da2, R*(P4) ^ true, Ack*(P4, PCom) ^ true, Q**(PCom) ^ false)),

([Q**(Pcom)][E}(Msg(P2, Pcom) ^ Da2, Ack*(Pcom, P2) ^ true, Msg(Pcom, P5) ^ Da2, R*(Ps) ^ true, Ack*(P5, Pcom) ^ true, Q**(Pcom) ^ false)), R(P2) ^ - R(P2) © E);

T3/P3: [R(Ps)](Exec(P3, A3) ^ Das, [Q**(Pcom)]{E}(Msg(P3, Pcom) ^ Das, Ack*(Pcom, P3) ^ true,Msg(Pcom, P6,i) ^ Das, R*(P6,i) ^ true, Ack*(P6,i, Pcom) ^ true, Q**(Pcom) ^ false), R(P3) ^ - R(P3) © E); T4/P4: [R(P4)](Exec(P4, A4,) ^ Da4, [Q**(Pcom)]{E}(Msg(P4, Pcom) ^ Da4, Ack*(Pcom, P4) ^ true, Msg(Pcom, P6,2) ^ Da4, R*(P6,2) ^ true, Ack*(P6,2, Pcom) ^ true, Q**(Pcom) ^ false), R(P4) ^ - R(P4) © E);

T5/P5: [R(Ps)](Exec(Ps, A5) ^ Das, [Q**(Pcom)]{E}(Msg(P5, Pcom) ^ Da5, Ack*(Pcom, P5) ^ true, Msg(Pcom, Pe,3) ^ Das, R*(P6,3) ^ true, Ack*(P6,3, Pcom) ^ true, Q**(Pcom) ^ false), R(Ps) ^ - R(Ps) © E);

T6/P6: [R*(P6,i) & R*(P6,2) & R*(P6,3)](Exec(P6,i, Da3) ^ D<u, Exec(P6,22, Da4) ^ D6,2, Exec(P6,33, Da5) ^ De,3,

[Q**(Pcom)]{E}(Msg(P6,1, Pcom) ^ D6,i, Msg(P6,2, Pcom) ^ D6,2, Msg(P6,3, Pcom) ^ D^3, Ack*(Pcom, P6,i) ^ true, Ack*(Pcom, Pfi.2) ^ true, Ack*(Pcom, P6,3) ^ true, Msg(Pcom, Pi) ^ D6,i, Msg(Pcom, Pi) ^ D6,2, Msg(Pcom, Pi) ^ D6,3, R*(Pi) ^ true, Ack*(Pi, Pcom) ^ true, Q**(Pcom) ^ false) © E);

Ti/Pi: [R(Pi)](Exec(Pi, Ai,) ^ Da7, [Q**(Pcom)]{E}(Msg(Pi, Pcom) ^ Da7, Ack*(Pcom, Pi) ^ true, Msg(Pcom, Ps) ^ Da7, R*(Ps) ^ true, Ack*(Ps, Pcom) ^ true, Q**(Pcom) ^ false), R(Pi) ^ - R(Pi) © E);

T8/P8: [R(P8)KExec(P8, As) ^ Das, [Q**(Pcom)]{E}(Msg(Ps, Pcom) ^ Das, Ack*(Pcom, Ps) ^ true, Msg(Pcom, P9) ^ Das, R*(Pq) ^ true, Ack*(P9, Pcom) ^ true, Q**(Pcom) ^ false), R(Ps) ^ - R(P8) © E);

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

T9/P9: [R(P9)](Exec(P9, A9) ^ Dap, [Q**(Pcom)]{E}(Msg(P9, Pcom) ^ Dap, Ack*(Pcom, P9) ^ true, Msg(Pcom, P10) ^ Dap, R*(Pio) ^ true, Ack*(Pio, Pcom) ^ true, Q**(Pcom) ^ false), R(P9) ^ - R(P9) © E);

T10/P10: [R(Pio)](Exec(Pio, A 10) ^ Daio,

[ ai]([Q**(Pcom)]{E}(Msg(Pio, Pcom) ^ Daio, Ack*(Pcom, P10) ^ true,

Msg(Pcom, P11, Daio) ^ Daio, Ack*(Pii, Pcom) ^ true,

R*(Pii) ^ true, Q**(Pcom) ^ false) ©

© ([a2]([Q**(Pcom)]{E}(Msg(Pi0, Pcom) ^ Daio, Ack*(Pcom, P10) ^ true, Msg(Pcom, P12) ^ Daio, Ack*(Pi2, Pcom) ^ true,

R*(Pi2) ^ true, Q**(Pcom) ^ false) ©

© ([as]([Q**(Pcom)]{E}(Msg(Pio, Pcom) ^ Daio, Ack*(Pcom, P10) ^ true, Msg(Pcom, P13) ^ Daio, Ack*(Pi3, Pcom) ^ true, R*(Pis) ^ true,

Q**(Pcom) ^ false) © E))), R(Pio) ^ - R(Pio) © E); T11/P11: [R(Pn)](Exec(Pn, A11) ^ Daii,

[Q**(Pcom)]{E}(Msg(Pii, Pcom) ^ Daii, Ack*(Pcom, P11) ^ true, Msg(Pcom, P14) ^ Daii, Ack*(Pi4, Pcom) ^ true, R*(Pi4) ^ true, Q**(Pcom) ^ false), R(Pii) ^ - R(Pii) © E);

T12/P12: [R(Pi2)](Exec(Pi2, A 12) ^ Da12, [Q**(Pcom)]{E}(Msg(Pi2, Pcom) ^ Da12, Ack*(Pcom, P12) ^ true, Msg(Pcom, P14) ^ Da12, Ack*(Pi4, Pcom) ^ true, R*(Pi4) ^ true, Q**(Pcom) ^ false), R(Pi2) ^ - R(Pi2) © E);

ТЫЛз: [R(Pi3)](Exec(Pi3, A 13) ^ Dah, [Q**(Pcom)]{E](Msg(Pl3, Pcom) ^ Da¡3, Ack*(Pcom, P13) ^ true, Msg(Pcom, P14) ^ Da13, Ack*(Pi4, Pcom) ^ true, R*(Pi4) ^ true, Q**(Pcom) ^ false), R(Pi3) ^ - R(Pi3) © E);

T14/P14: [R(Pi4)](Exec(Pi4, A 14) ^ Da14, [Q**(Pcom)]{E}(Msg(Pi4, Pcom) ^ Da14, Ack*(Pcom, P14) ^ true, Msg(Pcom, P15) ^ Da14, Ack*(Pi5, Pcom) ^ true, R*(Pi5) ^ true, Q**(Pcom) ^ false), R(Pi5) ^ - R(Pi5) © E);

T15/P15: [R(Pi5)](Exec(Pi5, A 15,) ^ Da15, [Q**(Pcom)]{E}(Msg(Pi5, Pcom) ^ Da15, Ack*(Pcom, P15) ^ true, Q**(Pcom) ^ false), R(Pi5) ^ - R(Pi5) © E).

При составлении приведенных выражений использована следующая нотация (из алгебры алгоритмов Глушкова) для оператора, подобного оператору if в процедурно-ориентированных языках:

[a](A © B).

Данное выражение означает, что при истинности условия a выполняется действие A, а при его ложности - действие B. Данный оператор может использоваться в следующей частной форме:

[a](A © E),

где E - «пустое» действие.

Оператору цикла соответствует следующее выражение:

[a]{A}.

Это означает, что после каждой проверки условия a, если оно оказывалось ложным, циклически выполняется оператор A до тех пор, пока условие a не станет истинным.

Развернутые комментарии к системе Х2 логико-алгебраических операционных выражений

Используемые ЛАОВ относятся к классу непосредственно исполнимых моделей и реализуются акторами-переходами в виде программных модулей. Условно будем считать, что эти модули «размещаются» на концептах-

позициях. Работа сетевого приложения начинается с запуска программного модуля, реализующего выражение для перехода Ts:

Ts/Po: [R*(Start)] (R*(Po) ^ true © E),

где запись TJPoo означает, что актор-переход Ts реализуется на концепте-позиции Po. Далее слово «концепт» будет опускаться. Запись [R*(Start)] означает, что запуск приложения осуществляется при R*(Start) = true; символ звездочки указывает на то, что после успешной проверки истинного значения высказывания R*(Start) на истинность его значение «по умолчанию» становится ложным. Запись R*(Po) ^ true означает активизацию позиции Po, что приводит к передаче управления программному модулю, реализующему следующее выражение To/Po и размещенному на той же позиции Po. Затем истинное значение высказывания R*(Po) «сбрасывается», т.е. оно становится ложным, на что указывает по умолчанию символ звездочки.

В процессе программной интерпретации следующего выражения To/Po выполняются следующие действия. Запись [R*(Po)] означает, что в модуле реализуется ожидание истинного значения высказывания R*(Po), которое поступает из модуля Ts/Po. Звездочка здесь и далее имеет описанный ранее смысл. При интерпретации выражения Exec(Po, Ao) ^ DAo в модуле To/Po на позиции Po происходит выполнение оператора Ao и формируется результат Dao. Стрелка соответствует операции присваивания нового значения бинарной функции Exec. Записи [Q**(Pcom)]{E} соответствует процесс ожидания состояния готовности диспетчера Comm пиринговой РВС к приему сообщения с результатом Dao, после чего выполняется операция Msg(Po, Pcom) ^ Dao передачи сообщения из позиции Po в позицию Pcom. Здесь Msg - бинарная функция. Две звездочки у символа Q означают, что от позиции Po модуля To/Po циклически направляются опрашивающие сообщения к позиции Pcom до тех пор, пока не будет получено сообщение о готовности диспетчера comm к приему информационного сообщения с результатом Dao. Оператору Ack* (Pcom, Po) ^ true соответствует получение позицией Po квитирующего сообщения от позиции Pcom.

При программной интерпретации выполнения операции Msg(Pcom, Pi) ^ ^ Dao результат Dao передается от позиции Pcom к следующей позиции Pi, реализуемой модулем Ti/Pi. Затем при помощи операции R*(Pi) ^ true управление от модуля To/Po через позицию Pcom передается модулю Ti/Pi с последующей посылкой квитирующего сообщения от позиции Pi к позиции Pcom. Последнее действие реализуется путем интерпретации операции Ack*(Pi, Pcom) ^ true. Операции Q**(Pcom) ^ false - освобождение позиции

Pcom диспетчера, и R(Po) <--1 R(Po) - для исключения повторного выполнения

модуля To/Po.

В заключение комментариев отмечается, что во всех выражениях для системы ЛАОВ включение в качестве аргумента в предикате или функции позиции Pcom означает, что необходимо, в зависимости от окружающего контекста, либо послать запрос Q**(Pcom) о состоянии узла-диспетчера comm и принять от него ответ, либо послать от какого-либо модуля с реализованной позицией Po сообщение с данными (например, Msg(Po, Pcom) для последующей передачи очередному модулю (например, Msg(Pcom, Pi).

Логико-алгебраические операционные выражения предназначены для программирования декларативно-императивной составляющей представления знаний о работе распределенного пирингового приложения для РВС. Полученное приложение соответствует функциональной архитектуре РВС. Непосредственная исполнимость ЛАОВ означает на практике, что только они могут быть последним этапом сетевой технологии, предшествующим кодированию программы для распределенного приложения.

На этом теоретическая часть настоящей работы окончена. Главным отличием предлагаемой методики является непосредственная исполнимость формализованных спецификаций, основанных на ЛАОВ, что ускоряет создание управляемых приложениями функциональных архитектур сетевых РВС. Вопросы проектирования РВС на основе концептуального подхода рассматривались также в работах [15-21], в которых не ставилась задача обеспечения управляемости приложениями функциональных архитектур, но создан базис для настоящей работы.

3. Разработка распределенного пирингового приложения

Разработка программного обеспечения сети пиринговых узлов для выполнения распределенных вычислений разделяется на следующие этапы:

- разработка диспетчера узлов;

- разработка логики работы узла;

- разработка логики работы оператора.

Разработка диспетчера узлов

Диспетчер узлов предназначен для временного хранения передаваемых сообщений, заданий, данных и должен выполнять следующие задачи:

- загружать задачу для пиринговой сети из файла конфигурации;

- принимать подключения от доступных узлов сети;

- рассылать задачи подключенным узлам;

- принимать подключения от операторов на узлах;

- обрабатывать запросы от операторов на получение адресов других операторов;

- отслеживать статус работы операторов.

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

class TaskParser {

public:

TaskParser( const std::string& configFilepath ); std::vector<Task> GetTasks(); private:

bool ParseString(const std::string& strTask, AgentData& agent, std::string& nodeName); private:

std::ifstream configFile_;

J;_

Метод «TaskParser::ParseString» разбирает строку текстового файла и заполняет данными структуру «AgentData». Метод «TaskParserwGetTasks» возвращает список задач в виде вектора структур «Task»:

struct Task {

std::string nodeName; int numAgents = 0; std::vector<AgentData> agents; friend class boost::serialization::access; template<typename Archive>

void serialize( Archive& ar, const unsigned version ) {

ar& nodeName& numAgents& agents;

}

J;_

Для сетевого взаимодействия с узлами в программе диспетчера узлов реализован класс «ServerSocket». В данном классе реализованы методы для выполнения основных задач сетевого взаимодействия, таких как прослушивание подключений, отправка и прием сообщений, корректное закрытие соединения.

Класс «ServerSocket» включает в себя методы для установления и поддержания соединения с удаленным узлом:

- «ServerInit» - метод для первоначальной инициализации диспетчера

узлов;

- «Listen» - метод, осуществляющий запуск прослушивания новых подключений удаленных узлов;

- «CloseClientSockets» - метод, осуществляющий закрытие соединения с удаленными узлами;

- «BroadcastMessage» - метод, осуществляющий рассылку всем подключенным удаленным узлам сигнала о завершении процесса распределенных вычислений успешно или с ошибкой;

- «Send» - метод для отправки данных;

- «Recieve» - метод для приема данных.

Основная логика взаимодействия с удаленным узлом заключается в отправке ему задачи и реализована в функции «InitNode».

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

Разработка логики работы удаленного узла

Логика узла выполняется в основном потоке приложения. Основной задачей разработки программной логики узла является соединение с диспетчером узлов и получение от него задачи.

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

Реализация сетевого соединения с диспетчером узлов содержится в классе «ClientSocket». При создании нового объекта класса «ClientSocket» создается новый объект сокета, который хранится как приватная переменная

этого класса. Таким образом, один экземпляр класса «ClientSocket» представляет отдельную сетевую единицу и включает в себя методы для работы с со-кетом. Методы класса схожи по названию и предназначению с методами класса «ServerSocket», рассмотренного выше, за исключением методов «Connect» - метод, осуществляющий подключение к серверу по необходимому сетевому адресу, и «Disconnect» - метод для корректного отсоединения от сервера.

Разработка логики работы оператора

Основной задачей оператора является прием управления от родительских операторов, обработка данных и дальнейшая передача управления дочерним операторам.

Весь программный модуль работы оператора реализован в классе «Agent». Основными методами класса являются следующие:

- <AgentThread» - основной метод класса, описывает логику работы оператора;

- «WaitParents» - метод класса, осуществляющий ожидания управления от родительских операторов;

- «DelegateChilds» - метод класса, выполняющий передачу управления дочерним операторам.

При создании объекта класса ему передается структура «AgentData». В ней содержится информация о положении текущего оператора в схеме распределенной вычислительной сети, информация о соседних операторах и номер порта, который будет прослушивать сокет текущего оператора.

Описание полей структуры приведено в табл. 2.

Таблица 2

Описание полей структуры «AgentData»

Название переменной Описание

«agentName» Имя агента

«listenPort» Номер порта, который прослушивает сокет текущего агента

«isChildFork» Логическая переменная, сигнализирующая о том, является ли переход к дочерним узлам параллельным

«isParentFork» Логическая переменная, сигнализирующая о том, является ли переход от родительских операторов параллельным

«parentAgents» Вектор, содержащий имена родительских операторов

«childAgents» Вектор, содержащий имена дочерних операторов

Тестирование и отладка пирингового приложения на отдельном узле ТСР/1Р-сети

Работа каждого оператора при тестировании имитируется и сопровождается выводом данных об узле на экран консоли. Было проведено тестирование на виртуальной сети на одном компьютере без учета времени работы сети, а также тестирование на реальной локальной сети с учетом времени работы сети. По схеме соединения операторов в графе, приведенном на рис. 1, был создан конфигурационный файл приложения, содержание которого дано в третьей колонке табл. 1.

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

Далее диспетчер узлов начинает ожидать подключения агентов (операторов). После того как все агенты подключились, диспетчер узлов переходит в режим ожидания. Он ожидает сигнала от каждого агента об успешном выполнении или появлении ошибки. После получения сигналов от всех агентов диспетчер узлов рассылает всем узлам сигнал об успешном или аварийном завершении. На этом вычисления завершаются.

Вывод консоли удаленного узла также содержит подробные сведения о его работе и приведен на рис. 4.

На рис. 5 приведен вывод консоли удаленного узла на примере узла Уо. Порядок действий остальных улов является аналогичным. Первоначально происходит попытка установления соединения с диспетчером узлов. При успешном соединении узел переходит в режим ожидания задачи. Как только задача будет получена, узел запустит отдельные потоки для выполнения своих агентов (операторов), а сам перейдет в режим ожидания сигнала завершения от диспетчера узлов.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

Тестирование работы пирингового приложения в локальной ТСР/1Р-сети

Для проведения тестирования и определения среднего времени работы приложения в реальной локальной сети была разработана утилита тестирования. Приложение для тестирования вычислительной сети состоит из программы сервера и программы клиента. Основной задачей приложения для тестирования является запуск программы диспетчера узлов и программ удаленных узлов требуемое количество раз. Программа сервера предназначена только для тестирования работы приложения, и в рабочей версии ее присутствие не обязательно.

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

На рис. 6 показан вывод консоли программы сервера для тестирования.

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

описанная выше. После завершения работы диспетчера узлов сервер для тестирования снова запустит диспетчер узлов и также разошлет сигналы запуска подключенным клиентам. Такой алгоритм повторится требуемое количество раз. На рис. 7 показан вывод консоли программы клиента для тестирования.

C:\WI N DOWS\sy stem 12\ст d. ex е Сервер запущен

Конфигурационный файл успешно разобран Прослушивание подключений...

127.0.0.1:1059 -127.0.0.1:1061 -127.0.0.1:1062 -127.0.0.1:1063 -127.0.0.1:1064 -127.0.0.1:1065 -127.0.0.1:1066 -127.0.0.1:1067 -127.0.0.1:106В -

Новый узел подключен

Новый узел подключен

Новый узел подключен

Новый узел подключен

Новый узел подключен

Новый узел подключен

Новый узел подключен

Новый узел подключен

Новый узел подключен Требуемое число клиентов подключено

Рассылка задач узлам...

Задача Задача Задача Задача Задача Задача Задача Задача Задача

успешно успешно успешно успешно успешно успешно успешно успешно успешно

выслана выслана выслана выслана выслана выслана выслана выслана выслана

узлу: узлу: узлу: узлу: узлу: узлу: узлу: узлу: узлу:

Все задачи успешно разосланы

Работа агентов... Новый art Новый аг( Новый аг( Новый аг( Новый аг( Новый аг( Новый аг( Новый аг( Новый аг( Новый аг( Новый аг( Новый аг( Новый аг( Новый аг( Новый аг( Агент А1 завершился успешно Агент А2 завершился успешно Агент A3 завершился успешно Агент А4 завершился успешно Агент А5 завершился успешно Агент А6 завершился успешно Агент А7 завершился успешно Агент AS завершился успешно Агент А9 завершился успешно Агент А12 завершился успешно Агент А13 завершился успешно Агент А14 завершился успешно Агент АО завершился успешно Работа агентов успешно завершена

127.0.0.1: 127.0.0.1: 127.0.0.1: 127. О. 0.1: 127.0.0.1: 127.0.0.1: 127.0.0.1: 127.0.0.1: 127.0.0.1: узлам

УО Y1 Y2 УЗ У4 У5 У6 У7 У5

1065 1062

1066 1061

1063 105 9 1067 106S

1064

подключен 127.0. 0. 1 1069 АО

подключен 127. 0. 0. 1 1073 А1

подключен 127. 0. 0. 1 1071 А2

подключен 127. 0. 0. 1 1074 A3

подключен 127. 0. 0. 1 1072 А4

подключен 127. 0. 0. 1 1075 А5

подключен 127. 0. 0. 1 107S А6

подключен 127. 0. 0. 1 1076 А7

подключен 127. 0. 0. 1 10S1 AS

подключен 127. 0. 0. 1 10S2 А9

подключен 127. 0. 0. 1 10S4 А10

подключен 127. 0. 0. 1 10S0 All

подключен 127. 0. 0. 1 10S5 А12

подключен 127. 0. 0. 1 1079 А13

подключен 127.0. 0. 1 10S6 А14

Рис. 4. Вывод консоли программы диспетчера узлов

Соединение с диспетчером узлов установлено

Ожидание задачи от диспетчера узлов Задача получена

Узел: УО

Операторы узла: АО А1 А2

[ АО ] Ожидание сигнала о начале вычислений от диспетчер узлов

[ А1 ] Ожидание данных от родительских узлов: АО

[ А2 ] Ожидание данных от родительских узлов: А1

[ АО ] Сигнал старта получен

Оператор АО успешно выполнен

[ АО ] Отправка данных дочернем узлам

I АО ] Данные успешно отправлены дочерним узлам: А1

[ АО ] Ожидание данных от родительских узлов: А14

I А1 ] Данные получены: АО

Оператор А1 успешно выполнен

[ А1 ] Отправка данных дочерней узлам

I А1 ] Данные успешно отправлены дочерним узлам: А2

I А2 ] Данные получены: А1

Оператор А2 успешно выполнен

[ А2 ] Отправка данных дочернем узлам

I А2 ] Данные успешно отправлены дочерним узлам: АЗ А4 А5 I АО ] Данные получены: А14 Вычисления завершены успешно.

Рис. 5. Вывод консоли программы удаленного узла

Введите количества узлов в сети: 9 Введите желаемое количество запусков: 5 Ожидание подключения тестовых клиентов...

Рис. 6. Вывод консоли сервера для тестирования

Рис. 7. Вывод консоли клиента для тестирования

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

Описание результатов тестирования в локальной ТСР/1Р-сети

Для тестирования пиринговой сети в реальных условиях было задействовано 10 компьютеров, объединенных в локальную ТСР/1Р-сеть. Один из компьютеров являлся сервером и осуществлял функцию управления. На него были помещены исполняемые файлы диспетчера узлов и программы сервера для тестирования, а также конфигурационный файл, содержащий текстовое представление графа. Остальные 9 компьютеров выступали в роли удаленных

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

Ручной единичный запуск приложения показал успешную работу приложения с учетом реальной сетевой нагрузки на приложение. Вывод консоли диспетчера узлов при работе в локальной сети приведен на рис. 8.

Сервер запущен

Конфигурационный файл успешно разобран Прослушивание подключений... Новый узел подключен Новый узел подключен Новый узел подключен Новый узел подключен Новый узел подключен Новый узел подключен Новый узел подключен Новый узел подключен Новый узел подключен

Требуемое число клиентов подключено Рассылка задач узлам...

Задача успешно выслана узлу: 192.163.10.49:

Задача успешно выслана узлу: 192.168.10.36:

Задача успешно выслана узлу: 192.168.10.50:

Задача успешно выслана узлу: 192.168.10.32:

Задача успешно выслана узлу: 192.168.10.42:

Задача успешно выслана узлу: 192.168.10.43:

Задача успешно выслана узлу: 192.168.10.44:

Задача успешно выслана узлу: 192.168.10.45:

Задача успешно выслана узлу: 192.168.10.46:

Все задачи успешно разосланы узлам

192.168.10.49:7609 -192.168.10.30:1300 -192.168.10.50:2191 -192.168.10.32:1286 -192.168.10.42:2153 -192.168.10.43:29740 192.168.10.44:1398 -192.168.10.45:1789 -192.168.10.46:1434 -

YB Y1 Y2 Y3 Y4 - Y5 Y6 Y7 Y8

7609

1300

2191

1286

2153

29740

1398

1789

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

1434

Работа агентов. . .

Новый агент подключен - 192.168.10.49: Новый агент подключен - 192.168.10.50: Новый агент подключен - 192.168.10.49: Новый агент подключен - 192.168.10.49: Новый агент подключен - 192.168.10.43: Новый агент подключен - 192.168.10.42: Новый агент подключен - 192.168.10.44: Новый агент подключен - 192.168.10.45: Новый агент подключен - 192.168.10.42: Новый агент подключен - 192.168.10.42: Новый агент подключен - 192.168.10.46: Новый агент подключен - 192.168.10.46: Новый агент подключен - 192.168.10.36: Новый агент подключен - 192.168.10.32: Новый агент подключен - 192.168.10.32: Агент А1 завершился успешно Агент А2 завершился успешно Агент A4 завершился успешно Агент A3 завершился успешно Агент А5 завершился успешно Агент А6 завершился успешно Агент А7 завершился успешно Агент А8 завершился успешно Агент А9 завершился успешно Агент А12 завершился успешно Агент А13 завершился успешно Агент А14 завершился успешно Агент А0 завершился успешно Работа агентов успешно завершена

7610 -2192 -

7611 -

7612 -29741

2154 -1399 -1790 -

2155 -

2156 -

1435 -

1436 -1301 -1288 -1287 -

А0 AI А2 A3 - A4 А5 А6 А7 AS А9 А10 Ail А12 А13 А14

Рис. 8. Вывод консоли диспетчера узлов при работе в локальной сети

Далее было проведено 100 запусков приложения. Было получено время работы сети при каждом запуске и вычислено среднее время работы приложения с учетом реальных задержек сети. На рис. 9 показан вывод консоли программы сервера для тестирования.

Бремя работы сети при 60 запуске - 3 60S6S2 секунд

Бремя работы сети при 61 запуске - 3 608135 секунд

Бремя работы сети при 62 запуске - 3 769100 секунд

Время работы сети при 63 запуске - 3.057100 секунд

Время работы сети при 64 запуске - 3 071273 секунд

Бремя работы сети при 65 запуске - 3 284292 секунд

Бремя работы сети при 66 запуске - 2 713378 секунд

Время работы сети при 67 запуске - 3 528337 секунд

Время работы сети при 68 запуске - 2.810711 секунд

Время работы сети при 69 запуске - 3 593142 секунд

Бремя работы сети при 70 запуске - 3 834504 секунд

Бремя работы сети при 71 запуске - 2 948805 секунд

Время работы сети при 72 запуске - 2 904773 секунд

Время работы сети при 73 запуске - 2 518278 секунд

Время работы сети при 74 запуске - 2 793271 секунд

Бремя работы сети при 75 запуске - 3 724942 секунд

Бремя работы сети при 76 запуске - 3 645432 секунд

Время работы сети при 77 запуске - 3 789274 секунд

Время работы сети при 78 запуске - 3 551512 секунд

Время работы сети при 79 запуске - 3 833070 секунд

Бремя работы сети при 80 запуске - 2 591254 секунд

Бремя работы сети при 81 запуске - 3 571357 секунд

Время работы сети при 82 запуске - 3 302580 секунд

Время работы сети при 83 запуске - 3.489278 секунд

Время работы сети при 84 запуске - 3.438564 секунд

Бремя работы сети при 85 запуске - 3.417757 секунд

Бремя работы сети при 86 запуске - 3 029633 секунд

Время работы сети при 87 запуске - 3 258103 секунд

Время работы сети при 88 запуске - 2 780892 секунд

Время работы сети при 89 запуске - 3 211951 секунд

Бремя работы сети при 90 запуске - 3 0456S1 секунд

Бремя работы сети при 91 запуске - 2 976229 секунд

Бремя работы сети при 92 запуске - 3 300312 секунд

Время работы сети при 93 запуске - 2 981066 секунд

Время работы сети при 94 запуске - 3 802705 секунд

Бремя работы сети при 95 запуске - 2 708492 секунд

Бремя работы сети при 96 запуске - 3 033126 секунд

Бремя работы сети при 97 запуске - 3 022849 секунд

Время работы сети при 98 запуске - 3.481389 секунд

Время работы сети при 99 запуске - 3 024569 секунд

Среднее время работы сети при 100 запускал - 3.227716 секунд Корректное завершение тестов

Рис. 9. Вывод консоли программы сервера для тестирования

Все разработанные программы, в том числе программы, обеспечивающие работу Р2Р-сети, выполнены по предлагаемой технологии, созданной на основе декларативно-императивного и логико-алгебраического подходов. В ходе дальнейших экспериментов РВС на базе Р2Р-сети показала устойчивую работу. Модули-операторы работают согласованно и могут реализовы-вать произвольные алгоритмы, в том числе алгоритмы предварительно обученных искусственных нейронных сетей, реализуя концепцию «Сеть - это компьютер» в полном объеме.

Заключение

Предложена управляемая приложением функциональная архитектура пиринговой распределенной вычислительной системы, реализующая концепцию «Сеть - это компьютер». Предложены декларативно-императивный (де-

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

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

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

Список литературы

1. Manoj Kumar Mishra, Yashwant Singh Patel, Moumita Ghosh, Mund G. B. A Review and Classification of Grid Computing Systems // International Journal of Computational Intelligence Research. 2017. Vol. 13, № 3. P. 369-402.

2. Радченко Г. И. Распределенные вычислительные системы. Челябинск : Фотохудожник, 2012. 184 с.

3. Cabani A., Ramaswamy S., Itmi M., Haziqah Shukri S., Pecuchet J.-P. Distributed Computing Systems: P2P versus Grid Computing Alternatives // Innovations and Advanced Techniques in Computer and Information Sciences and Engineering. 2007. P. 47-52. doi: 10.1007/978-1-4020-6268-1_9

4. Giridhar Kumar D., SubbaRao Ch. D. V. Peer-To-Peer Computing: Architectures, Applications and Challenges // International Journal of Recent Technology and Engineering (IJRTE). 2019. Vol. 8, № 1S4. P. 630-636.

5. Kahanwal B., Singh T. P. The Distributed Computing Paradigms: P2P, Grid, Cluster, Cloud, and Jungle // International Journal of Latest Research in Science and Technology. 2012. Vol. 1, № 2. P. 183-187.

6. Quang Hieu Vu, Mihai Lupu, Beng Chin Ooi. Peer-to-Peer Computing Principles and Applications. Springer Publication, 2010. doi: 10.1007/978-3-642-03514-2

7. SD-WAN Software Defined программно-определяемая WAN-сеть. 2022. URL: https://www.tadviser.ru/index.php/Статья:SD-

WAN_(Software_Defined)_Программно-определяемая_WAN-сеть (дата обращения: 01.09.2023).

8. Zhenjie Yang, Yong Cui, Baochun Li, Yadong Liu, Yi Xu. Software-Defined Wide Area Network (SD-WAN): Architecture, Advances and Opportunities // 28th International Conference on Computer Communication and Networks (ICCCN). Valencia, Spain, 2019. P. 1-9. doi: 10.1109/ICCCN.2019.8847124

9. Youssfi M., Bouattane O., Bensalah M. A Parallel Computational Model Based on Mobile Agents for High Performance Computing // Contemporary Engineering Sciences. 2015. Vol. 8, № 15. P. 677-698. doi: 10.12988/ces.2015.55153

10. Bergenti F., Iotti E., Monica S., Poggi A. Agent-oriented model-driven development for JADE with the JADEL programming language // Comput. Lang. Syst. Struct. 2017. Vol. 50. P. 142-158. doi: 10.1007/978-3-319-93581-2_9

11. Publications by BOINC projects. 2018. URL: https://boinc.berkeley.edu/wiki/ Publications_by_BOINC_projects (дата обращения: 01.09.2023).

12. Anderson D. P. BOINC: A Platform for Volunteer Computing. University of California, Berkeley. Space Sciences Laboratory Berkeley, 2018. 37 p.

13. Welcome to the Worldwide LHC Computing Grid. URL: https://wlcg.web.cern.ch (дата обращения: 01.09.2023).

14. Зинкин С. А., Джафар М. С. Развитие информационно-коммуникационных инфраструктур распределенных вычислительных систем на основе концепции «Сеть - это компьютер» // Известия Юго-Западного государственного университета. 2018. Т. 22, № 4. С. 75-93.

15. Волчихин В. И., Карамышева Н. С., Горынина А. В., Зинкин С. А. Разработка сетевых агентно-базированных приложений на основе метакомпьютерной технологии // Известия высших учебных заведений. Поволжский регион. Технические науки. 2021. № 4. С. 3-25. doi: 10.21685/2072-3059-2021-4-1

16. Карамышева Н. С., Свищев Д. С., Попов К. В., Зинкин С. А. Реализация агентно-базированных метакомпьютерных систем и приложений // Известия Юго-Западного государственного университета. 2022. Т. 26, № 1. C. 148-171. doi: 10.21869/2223-1560-2022-26-1-148-171

17. Волчихин В. И., Карамышева Н. С., Зинкин С. А., Гурин Е. И. Алгоритмика, логика и моделирование агентно-базированных метакомпьютерных систем с повышенным уровнем параллельности // Известия высших учебных заведений. Поволжский регион. Технические науки. 2022. № 2. С. 5-25. doi: 10.21685/20723059-2022-2-1

18. Волчихин В. И., Карамышева Н. С., Свищев Д. С., Зинкин С. А. Реализация масштабируемых интеллектуальных систем и приложений на базе мобильных агентов // Известия высших учебных заведений. Поволжский регион. Технические науки. 2023. № 1. С. 44-63. doi: 10.21685/2072-3059-2023-1-4

19. Волчихин В. И., Карамышева Н. С., Митрохин М. А., Зинкин С. А. Реализация управляемой приложением функциональной архитектуры пиринговой распределенной вычислительной системы, определяемой концептуальными и логическими моделями искусственного интеллекта. I. Декларативный и логический подходы // Известия высших учебных заведений. Поволжский регион. Технические науки. 2024. № 1. С. 19-38. doi: 10.21685/2072-3059-2024-1-2

20. Волчихин В. И., Карамышева Н. С., Митрохин М. А., Зинкин С. А. Представление и структурирование знаний в семантико-ориентированной вычислительной среде. Часть I. Интеграция концептуальных графов и логических сетей на основе формализации структурированных ситуаций // Известия высших учебных заведений. Поволжский регион. Технические науки. 2023. № 2. С. 24-51. doi: 10.21685/20723059-2023-2-3

21. Волчихин В. И., Карамышева Н. С., Митрохин М. А., Зинкин С. А. Представление и структурирование знаний в семантико-ориентированной вычислительной среде. Часть II. Интерпретации концептуальных событийных сетевых моделей для заданных предметных областей // Известия высших учебных заведений. Поволжский регион. Технические науки. 2023. № 3. С. 41-71. doi: 10.21685/2072-30592023-3-4

References

1. Manoj Kumar Mishra, Yashwant Singh Patel, Moumita Ghosh, Mund G.B. A Review and Classification of Grid Computing Systems. International Journal of Computational Intelligence Research. 2017;13(3):369-402.

2. Radchenko G.I. Raspredelennye vychislitel'nye sistemy = Distributed computing systems. Chelyabinsk: Fotokhu-dozhnik, 2012:184. (In Russ.)

3. Cabani A., Ramaswamy S., Itmi M., Haziqah Shukri S., Pecuchet J.-P. Distributed Computing Systems: P2P versus Grid Computing Alternatives. Innovations and Advanced Techniques in Computer and Information Sciences and Engineering. 2007:47-52. doi: 10.1007/978-1-4020-6268-1_9

4. Giridhar Kumar D., SubbaRao Ch.D.V. Peer-To-Peer Computing: Architectures, Applications and Challenges. International Journal of Recent Technology and Engineering (IJRTE). 2019;8(1S4):630-636.

5. Kahanwal B., Singh T.P. The Distributed Computing Paradigms: P2P, Grid, Cluster, Cloud, and Jungle. International Journal of Latest Research in Science and Technology. 2012;1(2):183-187.

6. Quang Hieu Vu, Mihai Lupu, Beng Chin Ooi. Peer-to-Peer Computing Principles and Applications. Springer Publication, 2010. doi: 10.1007/978-3-642-03514-2

7. SD-WAN Software Defined programmno-opredelyaemaya WAN-set'. 2022. Available at: https://www.tadviser.ru/index.php/Stat'ya:SD-WAN_(Software_Defined)_ Programmno-opredelyaemaya_WAN-set' (accessed 01.09.2023).

8. Zhenjie Yang, Yong Cui, Baochun Li, Yadong Liu, Yi Xu. Software-Defined Wide Area Network (SD-WAN): Architecture, Advances and Opportunities. 28th International Conference on Computer Communication and Networks (ICCCN). Valencia, Spain, 2019:1-9. doi: 10.1109/ICCCN.2019.8847124

9. Youssfi M., Bouattane O., Bensalah M. A Parallel Computational Model Based on Mobile Agents for High Performance Computing. Contemporary Engineering Sciences. 2015;8(15):677-698. doi: 10.12988/ces.2015.55153

10. Bergenti F., Iotti E., Monica S., Poggi A. Agent-oriented model-driven development for JADE with the JADEL programming language. Comput. Lang. Syst. Struct. 2017;50:142-158. doi: 10.1007/978-3-319-93581-2_9

11. Publications by BOINC projects. 2018. Available at: https://boinc.berkeley.edu/wiki/ Publications_by_BOINC_projects (accessed 01.09.2023).

12. Anderson D.P. BOINC: A Platform for Volunteer Computing. University of California, Berkeley. Space Sciences Laboratory Berkeley, 2018:37.

13. Welcome to the Worldwide LHC Computing Grid. Available at: https://wlcg.web.cern.ch (accessed 01.09.2023).

14. Zinkin S.A., Dzhafar M.S. Development of information and communication infrastructures of distributed computing systems based on the concept of "The network is a computer". Izvestiya Yugo-Zapadnogo gosudarstvennogo universiteta = Proceedings of the South-West State University. 2018;22(4):75-93. (In Russ.)

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

15. Volchikhin V.I., Karamysheva N.S., Gorynina A.V., Zinkin S.A. Development of network agent-based applications based on metacomputer technology. Izvestiya vysshikh uchebnykh zavedeniy. Povolzhskiy region. Tekhnicheskie nauki = University proceedings. Volga region. Engineering sciences. 2021;(4):3-25. (In Russ.). doi: 10.21685/2072-3059-2021-4-1

16. Karamysheva N.S., Svishchev D.S., Popov K.V., Zinkin S.A. Implementation of agent-based metacomputer systems and applications. Izvestiya Yugo-Zapadnogo gosudar-stvennogo universiteta = Proceedings of the South-West State University. 2022;26(1): 148-171. (In Russ.). doi: 10.21869/2223-1560-2022-26-1-148-171

17. Volchikhin V.I., Karamysheva N.S., Zinkin S.A., Gurin E.I. Algorithms, logic and modeling of agent-based metacomputer systems with an increased level of parallelism. Izvestiya vysshikh uchebnykh zavedeniy. Povolzhskiy region. Tekhnicheskie nauki = University proceedings. Volga region. Engineering sciences. 2022;(2):5-25. (In Russ.). doi: 10.21685/2072-3059-2022-2-1

18. Volchikhin V.I., Karamysheva N.S., Svishchev D.S., Zinkin S.A. Implementation of scalable intelligent systems and applications based on mobile agents. Izvestiya vysshikh uchebnykh zavedeniy. Povolzhskiy region. Tekhnicheskie nauki = University proceedings. Volga region. Engineering sciences. 2023;(1):44-63. (In Russ.). doi: 10.21685/2072-3059-2023-1-4

19. Volchikhin V.I., Karamysheva N.S., Mitrokhin M.A., Zinkin S.A. The implementation of an application-driven functional architecture of a peer-to-peer distributed computing system defined by conceptual and logical models of artificial intelligence. I. The declarative and logical approaches. Izvestiya vysshikh uchebnykh zavedeniy. Povolzhskiy region. Tekhnicheskie nauki = University proceedings. Volga region. Engineering sciences. 2024;(1):19-38. (In Russ.). doi: 10.21685/2072-3059-2024-1-2

20. Volchikhin V.I., Karamysheva N.S., Mitrokhin M.A., Zinkin S.A. Presentation and structuring of knowledge in a semantically oriented computational environment. Part 1. Integration of conceptual graphs and logical sets on the basis of formalization of structured situations. Izvestiya vysshikh uchebnykh zavedeniy. Povolzhskiy region. Tekhnich-eskie nauki = University proceedings. Volga region. Engineering sciences. 2023;(2):24-51. (In Russ.). doi: 10.21685/2072-3059-2023-2-3

21. Volchikhin V.I., Karamysheva N.S., Mitrokhin M.A., Zinkin S.A. Presentation and structuring of knowledge in a semantically oriented computational environment. Part 2. Interpretation of conceptual events of set models for given objective areas. Izvestiya vysshikh uchebnykh zavedeniy. Povolzhskiy region. Tekhnicheskie nauki = University proceedings. Volga region. Engineering sciences. 2023;(3):41-71. (In Russ.). doi: 10.21685/2072-3059-2023-3-4

Информация об авторах / Information about the authors

Владимир Иванович Волчихин

доктор технических наук, профессор, президент Пензенского государственного университета (Россия, г. Пенза, ул. Красная, 40)

E-mail: cnit@pnzgu.ru

Надежда Сергеевна Карамышева

кандидат технических наук, доцент кафедры вычислительной техники, Пензенский государственный университет (Россия, г. Пенза, ул. Красная, 40)

E-mail: karamyshevans@yandex.ru

Максим Александрович Митрохин

доктор технических наук, доцент, заведующий кафедрой вычислительной техники, Пензенский государственный университет (Россия, г. Пенза, ул. Красная, 40)

E-mail: vt@pnzgu.ru

Сергей Александрович Зинкин доктор технических наук, профессор, профессор кафедры вычислительной техники, Пензенский государственный университет (Россия, г. Пенза, ул. Красная, 40)

E-mail: zsa49@yandex.ru

Vladimir I. Volchikhin Doctor of engineering sciences, professor, president of Penza State University (40 Krasnaya street, Penza, Russia)

Nadezhda S. Karamysheva

Candidate of engineering sciences, associate

professor of the sub-department of computer

engineering, Penza State University

(40 Krasnaya street, Penza, Russia)

Maksim A. Mitrokhin Doctor of engineering sciences, associate professor, head of the sub-department of computer engineering, Penza State University (40 Krasnaya street, Penza, Russia)

Sergey A. Zinkin

Doctor of engineering sciences, professor, professor of the sub-department of computer engineering, Penza State University (40 Krasnaya street, Penza, Russia)

Авторы заявляют об отсутствии конфликта интересов / The authors declare no conflicts of interests.

Поступила в редакцию / Received 18.09.2023

Поступила после рецензирования и доработки / Revised 21.12.2023 Принята к публикации / Accepted 15.02.2024

i Надоели баннеры? Вы всегда можете отключить рекламу.