Роб Кёртен - Введение в QNX/Neutrino 2. Руководство по программированию приложений реального времени в QNX Realtime Platform

Чтобы не вносить излишней путаницы, до сих пор я избегал вопроса о применении обмена сообщениями в сети, хотя реально это основополагающий фактор гибкости 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);

}

В то время, я говорил, что это был пример «обмена сообщениями в сети». Клиент соединяется с сервером, определяемым тройкой ND/PID/CHID (и который оказывается на другом узле), а сервер выполняет на своем канале MsgReceive() . Клиент и сервер в данном случае абсолютно аналогичны клиенту и серверу в варианте с локальным узлом. Собственно, прекратить читать книгу можно прямо здесь — в передаче сообщений по сети нет ничего хитрого. На вам, наверное, любопытно как все это происходит? Читайте дальше!

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

Вот рисунок, иллюстрирующий эти этапы:

Обмен сообщениями в сети. Отметьте, что модуль qnet разделен на две части.

На данном рисунке наш узел называется magenta , а целевой узел по аналогии с примером называется wintermute .

Рассмотрим взаимодействия, которые происходят, когда программа-клиент использует qnet , чтобы обратиться к серверу через сеть:

1. Функции open() клиента было предписано открыть файл с именем, которое начинается с /net . (Имя /net — имя по умолчанию, объявляемое администратором qnet — см. документацию по QNX/Neutrino, раздел npi-qnet ). Клиент понятия не имеет, кто именно отвечает за конкретное имя пути, поэтому он соединяется с администратором процессов (шаг 1), чтобы выяснить, кому принадлежит ресурс. Это выполняется автоматически и не зависит от того, передаем ли мы сообщения по сети или нет. Поскольку все ресурсы, имена которых начинаются с /net , принадлежат администратору qnet , администратор процессов отвечает клиенту, что относительно этого имени пути надо спросить администратор qnet .

2. Клиент теперь посылает сообщение потоку администратора qnet , надеясь, что тот будет способен обработать запрос. Однако администратор qnet на этом узле не может предоставить клиенту конечный сервис, поэтому он сообщает клиенту, что тот должен обратиться к администратору процессов на узле wintermute . (Это делается специальным перенаправляющим сообщением, в котором содержатся ND/PID/CHID сервера, к которому надо обратиться взамен.) Это перенаправление также автоматически обрабатывается клиентской библиотекой.

3. Клиент соединяется с администратором процессов на узле wintermute . Это включает в себя отправку сообщения другому узлу с помощью драйверного потока qnet . Процесс qnet клиентского узла получает сообщение и транспортирует его через сетевую среду удаленному qnet , который, в свою очередь, доставляет его администратору процессов на узле wintermute . Администратор процессов этого узла разрешает остальную часть имени пути (в нашем примере это /home/rk/filename ) и отвечает перенаправляющим сообщением. Это сообщение передается обратно — через qnet сервера по сетевой среде к qnet клиента и, наконец, самому клиенту. Поскольку в этом сообщении содержатся ND/PID/CHID нужного сервера, предоставляющего конечный сервис, клиент теперь знает, к кому обращаться (в нашем примере это администратор удаленной файловой системы).

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

После того как пройдены этапы 1 и 3, все дальнейшие коммуникации осуществляются аналогично этапу 4. В вышеприведенном примере все сообщения типа open() , read() и close() идут по маршруту, описанном в этапе 4. Заметьте, что вся последовательность рассмотренных событий была запущена вызовом open() , но само сообщение open() все равно дошло до сервера-адресата так, как это описано этапом 4.