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

Кёртен Роб

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

Функция MsgReceive (при использовании в сети) тоже оказывается под влиянием. На момент разблокирования функции MsgReceive на стороне сервера

qnet

может еще не успеть передать все данные клиента. Это делается из соображений производительности.

В структуре

struct _msg_infо

, передаваемой функции MsgReceive в качестве последнего параметра (мы подробно рассматривали эту структуру в параграфе «Кто послал сообщение?»), есть два флага:

msglen	Указывает на фактическое количество данных, переданное функцией MsgReceive ( qnet любит передавать по 8Кб за один раз).
srcmsglen	Указывает на количество данных, которое клиент хотел передать (определяется клиентом).

Таким образом, если бы клиент желал передать 1 мегабайт данных по сети, MsgReceive сервера разблокировалась бы, установив параметр msglen в значение 8192 (указывая, что 8192 байта доступны в буфере); параметр srcmsglen при этом равнялся бы 1048576 (указывая, что клиент пытался переслать 1 мегабайт данных).

Затем сервер использует MsgRead для получения остальной части данных из адресного пространства клиента.

Несколько замечаний о дескрипторах узлов

Еще одна любопытная вещь, которой мы еще не касались в обсуждениях обмена сообщениями, — это дескрипторы узлов, для краткости обозначаемые «ND» (сокр. от Node Descriptor — прим. ред.).

Вспомните: в наших примерах мы использовали символьные имена узлов, например,

/net/wintermute

. В QNX4 (предыдущая версия QNX до появления QNX/Neutrino) вся работа в сети была основана на концепции идентификатора узла, небольшого целого числа, уникально определяющего узел сети. Таким образом, в терминах QNX4 мы говорили бы что-то вроде «узел 61», или «узел 1», и это отражалось бы и на вызовах функций тоже.

При работе в QNX/Neutrino все узлы внутренне представляются 32-разрядными числами, но эти числа не являются уникальными в сети! Я имею в виду, что узел

wintermute

может думать об узле

spud

как об узле с дескриптором 7, в то время как сам узел

spud

может думать, что дескриптор 7 соответствует узлу

magenta

. Поясню подробнее, чтобы дать полную картину происходящего. В приведенной ниже таблице сведены примерные дескрипторы узлов, которые могли бы использоваться для описания трех узлов:

wintermute

,

spud

и

foobar

(не путать с аббревиатурой FUBAR — прим. ред. :-):

Узел	wintermute	spud	foobar
wintermute	0	7	4
spud	4	0	6
foobar	5	7	0

Обратите внимание, что каждый узел считает свой собственный дескриптор нулевым. Также отметьте, что для узла

spud

оба узла

wintermute

и

foobar

имеют дескриптор 7. Однако, для узла

foobar

узел

wintermute

имеет дескриптор 4, а узел

spud

 — 6. Как я и упоминал раньше, эти номера не уникальны в сети, но они уникальны на каждом узле. Вы можете относиться к ним, как к файловым дескрипторам — два процесса, когда обращаются к одному и тому же файлу, могут иметь для него как одинаковый дескриптор, так и нет — все зависит от того, кто, когда и который файл открывает.

К счастью, вам не надо беспокоиться о дескрипторах узлов по ряду причин:

• Большинство осуществляемых вами операций обмена сообщениями «с внешним миром» будут реализовываться с помощью вызовов функций высокого уровня (таких как функция open, приведенная в примере выше).

• Дескрипторы узлов не кэшируются — предполагается, что получив дескриптор, вы используете немедленно и забудете про него.

• Существует ряд библиотечных функций, предназначенных для преобразования имени пути (например,

/net/magenta

) в дескриптор узла.

Чтобы работать с дескрипторами узлов, вам понадобится подключить файл

<sys/netmgr.h>

, потому что он содержит прототипы семейства функций netmgr_*.

Для преобразования строки в дескриптор узла используется функция netmgr_strtond. После получения дескриптора узла его следует сразу же применить в вызове функции ConnectAttach. Не пытайтесь сохранять его какой-либо структуре данных! Веским основанием для этого является то, что администратор сети может решить повторно использовать дескриптор после отключения всех соединений с узлом.

Так что если вы получили дескриптор «7» для узла

/net/magenta

, подсоединились к нему, передали сообщение и затем отсоединились, то существует возможность того, что администратор сети заново назначит дескриптор «7» другому узлу.

Поскольку дескрипторы узлов в сети не уникальны, возникает вопрос: «А как передавать эти штуки по сети?» Очевидно, взгляды узла

magenta

и узла

wintermute

на дескриптор «7» будут радикально отличаться. Существуют два способа решения этой проблемы:

• Не передавать по сети дескрипторы узлов и пользоваться символьными именами (например,

/net/wintermute

).

• Применять функцию netmgr_remote_nd.

Первый метод хорош как универсальное решение. Второй метод достаточно удобен на практике.

int netmgr_remote_nd(int remote_nd, int local_nd);

Эта функция принимает два параметра, где remote_nd — дескриптор узла целевой машины, a local_nd — дескриптор узла, который нужно преобразовать из точки зрения локальной машины в точку зрения целевой. Результатом является дескриптор узла, корректный с точки зрения заданной удаленной машины.

Например, пусть

wintermute

— имя нашей локальной машины. У нас есть дескриптор узла «7», который является корректным на нашей локальной машине и указывает на узел

magenta

. Мы хотели бы выяснить, какой дескриптор узла использует узел

magenta

для связи с нашим узлом:

int remote_nd;

int magenta_nd;

magenta_nd = netmgr_strtond("/net/magenta", NULL);