Введение в QNX/Neutrino 2

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()