Теоретическое обоснование множественных программных магистралей сообщений

Суть идеи

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

Основные понятия

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

Обмен является асинхронным - т. е. приложение SENDER передаёт сообщение MSG процессу DEST путём его передачи диспетчеру сообщений MSGMG. MSGMGR, в свою очередь, помещает сообщение в конец очереди сообщений MQ. Очередь организована по принципу FIFO.

Периодически MSGMGR проверяет MQ на наличие сообщений, и при наличии таковых, доставляет их адресатам. У адресата это сообщение попадает в фильтр сообщений MF. MQ используется одна для всех сообщений и управляется на уровне ядра.

Итак, сформулируем задачи системы передачи сообщений и проведём анализ единой магистрали (SSB - Single Software Bus) и множественных магистралей (MSB - Multiply Software Bus).

Задачи системы передачи сообщений

1. возможность обмена данными между различными приложениями
2. возможность обмена данными между различными пользователями и системами
3. единый способ передачи и представления информации
4. единый способ управления приложениями

Анализ SSB (единственная магистраль сообщений)

Пункту 1 единая магистраль удовлетворяет. Она позволяет осуществлять межпроцессовое сообщение. Но возникает "но": передачу больших объёмов данных реализовать не позволяет. Почему? Да потому что пункт 3 требует единого аппарата (протокола) передачи и данных!

Рассмотрим практический пример:

• На SSB могут находиться приложения, обслуживающие медленные устройства (например, модем, принтер) и приложения, обслуживающие быстрые устройства (например видео- и аудио- кодеки). Ситуация совершенно реальная!
• В SSB типа FIFO поступают сообщения с данными: пакет для принтера, пакет для модема, пакет для аудиокодека, пакет для видеокодека, затем опять для принтера, для модема, для аудиокодека, для видеокодека, для аудиокодека, для видеокодека...
• Принтер обрабатывает пакет за 100 мс, модем за 200 мс, аудиокодек - 10 мс, и следующий пакет ждёт через 200 мс, видеокодек - за 5 мс, и следующий пакет ждёт через 100 мс. В результате принтер с модемом ещё не обработали свои сообщения, а аудио- и видеокодеки ждут следующей порции данных.

Выход: применение буферизации сообщений в более медленных "обработчиках", по это вызывает дополнительный расход памяти.

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

SSB не позволяет обмениваться сообщениями между разными пользователями и между приложениями в распределённых системах. Почему? Да потому что SSB - понятие локальное. На каждой системе по своей очереди, а обмен с помощью мостов между этими системами - это уже MSB.

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

Выводы:

• SSB удовлетворяет частично п. 1 и п. 3 и полностью п. 4.
• Совершенно не удовлетворяет п. 2, а на сегодняшний день удалённые или распределённые системы - хлеб насущный
• Из этого следует, что SSВ совершенно не удовлетворяет предъявляемым требованиям!

Анализ МSB (множественные магистрали сообщений)

Реализация межпроцессного взаимодействия как в SSB, так и в МSB удовлетворяет перечисленным выше принципам, причём МSB предоставляет разработчику гораздо больше средств:

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

При МSB возникает новое понятие - единое адресное пространство. Все магистрали имеют уникальный составной идентификатор, и с точки зрения приложения нет абсолютно никакой разницы между локальной магистралью и удалённой (сетевой). Это позволяет передавать данные и локально, и удалённо, применяя единые методы.

Как уже упоминалось ранее, МSB позволяет применить единые методы взаимодействия как при пакетных данных, так и при потоковых данных. Это гарантирует и единое представление информации.

Выводы:

• МSB полностью удовлетворяет всем четырём вышеперечисленным требованиям.
• Суммарно реализация МSB сложнее, но реализация каждого компонента проще.