IPC

Еще не завершенная серия статей со знаком ++ (С++ связь с зяыком С, С++ и Ява, С++ и Питон) открывает другой аспект рассматриваемого вопроса по заимодействию различных сред и различных процессов.


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


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


Коммуникации внутри одной програмы в приведенных примерах для передачи параметров от библиотеки на одном языке (скажем Ява), в библиотеку на другом языке (скажем С++) достаточно вызыва метода и сериализация происходит тривиальным образом. Все данные у нас на руках, они однозначно находятся в нужном нам адресном пространстве, их целостность гарантирована, отсутсвие потерь и так далее.


Теперь представим себе что наша библиотека находится дальше чем простой вызов ее функции. Например мы хотим передать данные из нашего приложения на Яве в приложение написанное на С++. В этом случае мы задействуем механизмы называемыме IPC (interprocess communications). Существует множество способов связи между процессами такие как: socket, dbus, shared memory, pipe, mail slots и множество других библиотек и техник.


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


Вопросы межпроцессорной комуникции решались в различных системах по разному. Так например компания microsoft в своей технолгии COM испльзует различные механизмы связи языковых сред с помощью универсального IDL и диспатчеров (которые могут общаться по номеру фукнции или вритуальной таблице функций). В Корбе так же используется язык IDL и механизм rpc.


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


Но кроме того, все эти техники не отвечают на еще один важный вопрос: "В каком виде данные должны передаваться от одного хоста к другому?"


Существует возможность передавать простые структуры путем их свертывания в бинарные блоики данных. Так напирмер для С++ вы можете исползьовать простую функцию memcpy(&struct, &socket, sizeof(struct_type)); В этом случае вы получите правильный результат если структура состоит только из примитивов и не имеет указателей или сложных типов. Но при этом вы должны самостоятельно проследить что бы получатель прочитал именно тот размер стркутуры на который была написана ваша программа, а так же проверить целостность данных и убедиться.


Гораздо дальше в этом направлении ушли языки на виртуальных машинах C#, Java, perl. В них предусмотрены эффективные механизмы помещения объектов в бинарную последовательность. Данные механизмы называются сериализацией.


В обоих случаях использвание sizeof(struct) в С++ и использование бинарных блоков для передачи между языками нам не походит так как чтение этих структур крайне затруднительно между различными процессами и машинами соединенными провадами. Структура бинарных данных может меняться, возникает необходимость слежения за версиями библиотек и в итогде требует создание целого комплекса по сераиализации данных с проверками и дополнительными подтвержденями.


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


Возникает резонный вопрос как возможно эффективно использовать межязыковую\межпроцессорную\межмашинную коммуникацию с минимальными потерями? При том, что бы эта среда была легко переносима между всеми известными нам средами работы и было бы понятно человеку, машине, яве, с++, x86, ppc, arm, pic процессорам?


Но на этот сложный вопрос уже ответили за меня. Этот универсальной язык разметки называется xml.


Осталось за кадром более менее полный перечен средств позволяющих делать межпроцессорную коммуникацию. Вот парочка из них, о кторых я хочу рассказать в слудующий раз: Altova Xml spy, java xml serilization, C# xlm serialization, xsd, xslt.


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