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

Кёртен Роб
Шрифт:

Чтобы не вносить излишней путаницы, до сих пор я избегал вопроса о применении обмена сообщениями в сети, хотя реально это основополагающий фактор гибкости QNX/Neutrino!

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

Ранее в этой главе я демонстрировал пример:

#include <fcntl.h>

#include <unistd.h>

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.

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