Читаем QNX/UNIX: Анатомия параллелизма полностью

QNX/UNIX: Анатомия параллелизма

Владимир Зайцев , Егор Горошко , Олег Иванович Цилюрик

В результате на узлах, где запущены службы глобальных имен, появятся имена /dev/name/globalи /dev/name/local. Каждый узел, на котором запущен gns-клиент или сервер, в одной и той же сети имеет один и тот же вид пространства имен на /dev/name/global. Каждый узел имеет локальное пространство имен /dev/name/local, являющееся локальным для данной машины и отличающееся от локального пространства имен на другой машине. (Кстати, помимо имен globalи localпод /dev/name/появится еще имя gns_serverили gns_local— имя, под которым регистрируется сам GNS-менеджер.)

Существует несколько функций API, относящихся к службе глобальных имен: name_attach, name_openи name_close. Программисты, знакомые с QNX 4, сразу «узнают» в них аналоги известных им функций qnx_name_attach, qnx_name_openи qnx_name_close. Приложения используют эти функции для объявления имени службы, связи со службой и отсоединения от службы.

Итак, чтобы объявить свое имя глобально в сети, приложение-сервер должно на узле, где в режиме сервера функционирует менеджер службы глобальных имен, объявить свою службу, выполнив вызов:

if (!(NameServer = name_attach(NULL, "MyService", NAME_FLAG_ATTACH_GLOBAL)))

return EXIT_FAILURE;

Флаг NAME_FLAG_ATTACH_GLOBALуказывает, что приложение-сервер объявляет свое имя глобально — в сети. Приложение, которое может подсоединить службу глобально, должно иметь право доступа root. После выполнения этого вызова в директории /dev/name/globalпоявится подсоединенное имя MyService(если бы третий аргумент вызова был установлен в ноль, это имя оказалось бы подсоединенным к /dev/name/localи было бы доступно только локально).

Регистрируя имя в пространстве глобальных имен, функция name_attachсоздает канал, идентификатор которого она возвращает в составе структуры NameServer. Отметим, что этот канал создается с определенными установленными флагами, задающими соответствующие действия системе:

• _NTO_CHF_UNBLOCK— доставлять владельцу канала импульс с кодом _PULSE_CODE_UNBLOCKи значением rcvidкаждый раз, когда Reply-блокированный клиент попытается разблокироваться (скажем, по получению сигнала или по таймеру);

• _NTO_CHF_DISCONNECT— доставлять владельцу канала импульс с кодом _PULSE_CODE_DISCONNECT, когда от процесса отсоединились все установленные соединения клиента (клиент выполнил name_closeна каждый свой name_openк имени сервера либо вообще умер);

• _NTO_CHF_COID_DISCONNECT— доставлять владельцу канала импульс с кодом _PULSE_CODE_COIDDEATHи значением coid(идентификатора соединения) для каждого соединения по этому каналу, когда канал закрывается.

Теперь, после создания канала, сервер может становиться на прием сообщений от клиентов:

rcvid = MsgReceive(NameServer->chid, &MsgBuf, sizeof MsgBuf);

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

if (MsgBuf.hdr_type >= _IO_BASE && Buffer.hdr.type <= _IO_MAX) {

MsgError(rcvid, ENOSYS);

continue;

}

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

С учетом этих деталей и организован нижеописанный сервер.

<p>Код процесса-сервера, использующего службу глобальных имен</p>

#include

/* На сервер могут приходить и импульсы. Как минимум. */

typedef struct _pulse msg_header_t;

/* Структура сообщения состоит из заголовка и буфера наших данных */

typedef struct _MsgBuf {

msg_header_t hdr;

char* Buffer;

} MsgBuf_t;

int main {

name_attach_t* NameServer;