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

Кёртен Роб

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

.

Мы еще вернемся к сообщениям, используемым функциями open, read и close (а также другими функциями) в главе «Администраторы ресурсов».

Особенности обмена сообщениями в сети

Итак, как только соединение установлено, все дальнейшие операции обмена сообщениями осуществляются в соответствии с этапом 4, как указано на рисунке. Это может привести вас к ошибочному представлению, что передача сообщений по сети идентична локальной. К сожалению, это не так. Вот список отличий:

• более длительные задержки;

• функция ConnectAttach возвращает признак успешного соединения независимо от того, является ли узел доступным или нет — реальный признак ошибки проявляется только при первой попытке передать

сообщение;

• функция MsgDeliverEvent не обеспечивает достаточной надежности;

• функции MsgReply, MsgRead, MsgWrite являются блокирующими вызовами (в локальном варианте они не являлись таковыми);

• функция MsgReceive не будет принимать все данные, посланные клиентом; сервер будет должен вызывать функцию MsgRead для получения окончательных остальных данных.

Более длительные времена задержки

Поскольку передача сообщений теперь выполняется в некоторой среде, а не прямым копированием «память-память» под управлением ядра, можно смело ожидать, что затраты времени на передачу сообщения будут существенно выше (100-Мбитный Ethernet в сравнении с 128-битным динамическим ОЗУ с тактированием 100 МГц будет ориентировочно на один или два порядка медленнее). В дополнение к этому также будут сказываться накладные расходы протокола и повторные попытки передачи в сбойных сетях.

Воздействие на функцию ConnectAttach

Когда вы вызываете функцию ConnectAttach, вы задаете ей идентификаторы ND, PID и CHID. Все, что при этом происходит в QNX/Neutrino, заключается в возврате ядром идентификатора соединения драйверному потоку

qnet

, изображенному выше на рисунке. Поскольку никакого сообщения еще не отправлено, вы не имеете информации о том, доступен ли узел, к которому вы только что подсоединились, или нет. В обычном случае это не проблема, потому что большинство клиентов не будет самостоятельно вызывать ConnectAttach и скорее воспользуется библиотечной функцией open, которая перед передачей сообщения «open» сама вызывает ConnectAttach. Это практически немедленно дает информацию о доступности удаленного узла.

Воздействие на функцию MsgDeliverEvent

Когда сервер вызывает функцию MsgDeliverEvent локально, ответственность за доставку события целевому потоку ложится на ядро. В сетевом варианте сервер также может вызывать функцию MsgDeliverEvent, но на этот раз ядро доставит «заготовку» этого события администратору

qnet

, возлагая на него ответственность за доставку этой «заготовки» удаленному

qnet

, который уже доставит реальное событие клиенту. Так вот, на стороне сервера с этим вызовом могут возникнуть проблемы, потому что он не является блокирующим. Это означает, после вызова MsgDeliverEvent сервер продолжает выполняться, и поздно уже оглядываться и говорить «Знаете, очень не хочется вас огорчать, но помните тот вызов MsgDeliverEvent? Так вот, он не сработал...»

Воздействие на функции MsgReply, MsgRead и MsgWrite

Чтобы уберечь функции MsgReply, MsgRead и MsgWrite от вышеупомянутой проблемы MsgDeliverEvent, эти функции при использовании их в сети преобразуются в блокирующие вызовы. В локальном случае они бы просто передали данные и разблокировались; в сети же мы должны либо удостовериться, что данные были доставлены клиенту (в случае MsgReply), либо собственно передать данные по сети клиенту или от него (в случае двух других функций).