Введение в QNX/Neutrino 2. Руководство по программированию приложений реального времени в QNX Realtime Platform - [36]
Ну вот, теперь вы знаете основы обмена сообщениями в архитектуре «клиент/сервер».
Не исключено, что вы сейчас думаете: «Так что, получается, чтобы открыть файл или записать данные, мне придется писать специализированные вызовы обмена сообщениями QNX/ Neutrino?!»
Нет, вам не придется программировать обмен сообщениями непосредственно — разве что если вам будет нужно копнуть совсем вглубь (об этом несколько позже). Действительно, позвольте мне показать Вам некоторую программу клиента, который делает передачу сообщений:
>#include
>#include
>int main(void) {
> int fd;
> fd = open("filename", O_WRONLY);
> write(fd, "Это обмен сообщениями\n", 24);
> close(fd);
> return (EXIT_SUCCESS);
>}
Видите? Обычная Си-программа, никаких хитростей.
Собственно обмен сообщениями реализован в Си-библиотеке QNX/Neutrino. Вы просто выдаете вызовы по стандарту POSIX 1003.1 и вызовы функций ANSI Си и Си-библиотека делает за Вас всю работу, связанную с обменом сообщениями.
В приведенном выше примере вызываются три функции, и посылаются три различных сообщения:
• open() — передала сообщение «open» («открыть»);
• write() — передала сообщение «write» («записать»);
• close() — передала сообщение «close» («закрыть»).
Мы обсудим сами сообщения более подробно, когда мы будем изучать администраторы ресурсов (в главе «Администраторы ресурсов»), а пока что единственное, что нам надо знать об этом — это сам факт, что были переданы сообщения различных типов.
Давайте на мгновение отвлечемся и сравним этот подход с тем, как бы это работало в традиционной операционной системе.
Клиентская программа осталась бы такой же — различия были бы скрыты в Си-библиотеке, поставляемой производителем программного обеспечения. В такой системе функция open() сделала бы системный вызов, ядро затем обратилось бы непосредственно к файловой системе, которая, в свою очередь, выполнила некоторые действия и возвратила бы дескриптор файла. Вызовы функций write() и close() работали бы аналогично
Итак? Есть ли преимущества в способе, который предлагает QNX/Neutrino? «Оставайтесь с нами!»
Распределенный обмен сообщениями
Предположим, что мы пожелали изменить приведенный выше пример, чтобы можно было «поговорить» с другим узлом сети. Вы, наверное, думаете, что для этого придется вызывать специальные функции, чтобы «попасть в сеть». Вот сетевой вариант нашей программы:
>#include
>#include
>int main(void) {
> int fd;
> fd = open("/net/wintermute/home/rk/filename", O_WRONLY);
> write(fd, "Это обмен сообщениями\n", 24);
> close(fd);
> return (EXIT_SUCCESS);
>}
Вы будете правы, если скажете, что в обеих версиях программы почти одинаковы. Так и есть.
В традиционной ОС функция open() библиотеки Си вызывает ядро, которое анализирует имя файла и говорит: «Опа! Это не на нашем узле…» Ядро затем вызывает сетевую файловую систему NFS, которая уже определяет, где в действительности находится файл >/net/wintermute/home/rk/filename. Затем, NFS вызывает сетевой драйвер и посылает сообщение ядру на узле >wintermute, которое повторяет весь процесс, описанный нами в нашем первоначальном примере. Заметьте, что в этом случае оказываются вовлеченными две файловые системы, одна из которых — сетевая файловая система (NFS) клиента, а вторая — удаленная. К сожалению, в зависимости от реализации как удаленной файловой системы, так и NFS, некоторые операции (например, блокировки файлов) могут работать некорректно из-за неполной совместимости.
В QNX/Neutrino функция open() Си-библиотеки создает точно такое же сообщение, какое она создала бы для локальной файловой системы, и посылает его файловой системе узла >wintermute. Локальная и удаленная файловые системы при этом абсолютно одинаковы.
Это и есть еще одна фундаментальная особенность QNX/Neutrino: распределенные операции выполняются в ней абсолютно «непринужденно», поскольку потребности клиентов изначально абстрагированы от служебных функций, обеспечиваемых серверами, благодаря механизму обмена сообщениями.
В традиционном ядре действует «двойной стандарт», когда локальные сервисы реализуются одним способом, а удаленные (сетевые) — совершенно другим.
Что это означает для вас
Обмен сообщениями в QNX/Neutrino элегантно реализован и распределен по сети. И что? Что с этого нам, программистам?
Ну, в первую очередь это означает, что ваши программы унаследуют от ОС те же характеристики — сделать их распределенными будет гораздо проще, чем в других ОС. Но самое полезное, на мой взгляд, преимущество заключается в том, что эта схема обеспечивает модульную структуру программного обеспечения, тем самым значительно упрощая процесс отладки и тестирования.
Вам, вероятно, доводилось участвовать в больших проектах, когда множество людей разрабатывают различные фрагменты целевого программного обеспечения. Разумеется, при этом кто-то опережает график, а кто-то запаздывает.
У таких проектов проблемы чаще всего возникают на двух этапах: на первоначальном, при распределении отдельных частей проекта между конкретными исполнителями, а также на этапе тестирования и интеграции, когда невозможно провести комплексные испытания системы из-за недоступности всех необходимых компонентов.
