QNX/UNIX: Анатомия параллелизма - Цилюрик Олег Иванович

 MsgError(rcvid, ENOSYS);

 continue;

}

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

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

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

#include <stdio.h>

#include <errno.h>

#include <stdlib.h>

#include <sys/dispatch h>

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

typedef struct _pulse msg_header_t;

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

typedef struct _MsgBuf {

 msg_header_t hdr;

 char* Buffer;

} MsgBuf_t;

int main() {

 name_attach_t* NameServer;

 MsgBuf_t MsgBuf;

 int rcvid;

 char BufReply[100];

 int flagWork = 1;

 /* Создаем глобальное имя /dev/name/global/MyService */

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

  NAME_FLAG_ATTACH_GLOBAL)))

  return EXIT_FAILURE;

 /* Становимся на петлю получения сообщений */

 while (flgWork) {

  if ((rcvid = MsgReceive(NameServer->chid, &MsgBuf,

   sizeof MsgBuf, NULL)) == -1) {

   printf("Ошибка при получении сервером MyService "

    "сообщения от клиентаn");

   fflush(stdout);

   break;

  }

  if (!rcvid) {

   // Получен импульс

   switch(MsgBuf.hdr.code) {

   case _PULSE_CODE_DISCONNECT:

    /* Поскольку для канала установлен флаг _NTO_CHF_DISCONNECT, ядро

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

       Сервер должен выполнить это со своей стороны сам, "сознательно"

       удалив маршрут от себя обратно к клиенту */

    ConnectDetach(MsgBuf.hdr.scoid);

    break;

   case _PULSE_CODE_UNBLOCK;

    /* Клиент пытается разблокироваться, не дождавшись ответа по Reply. Надо

       выполнить какие-то действия, чтобы корректно (для себя)

       обработать эту ситуацию, и все-таки отпустить этого клиента - ему

       ведь надо! При этом импульсе в MsgBuf.hdr.value приходит rcvid */

    MsgReply(MsgBuf.hdr.value.sival_int, EAGAIN, NULL, 0);

    break;

   default:

    break;

   }

   continue;

   // вновь уходим на петлю приема сообщений

  }

  /* Полученное сообщение находится в диапазоне системных сообщений

     ввода/вывода. Не обрабатываем. */

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

   MsgError(rcvid, ENOSYS);

   continue;

  }

  /* А вот это - сообщение для сервера. Обрабатываем. */

  if (MsgBuf.hdr.type <= 0x50001 || MsgBuf.hdr.type >= 0x500ff) {

   printf("Сервер получил сообщение неизвестно от"

    " кого с меткой %#xn", MsgBuf.hdr.type);

   strcpy(BufReply, "а кто это???");

  } else {

   printf("Сервер получил сообщение. "%s"n",

    MsgBuf.Buffer);

   strcpy(BufReply, "а, это ты, клиент");

  }

  MsgReply(rcvid, EOK, BufReply, strlen(BufReply) + 1);

 }

 // Конец петли получения сообщений

 /* Отсоединяемся от службы глобальных имен */

 name_detach(NameServer, 0);

 return EXIT_SUCCESS;

}

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

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

• Если локальный поставщик отсутствует или по каким-то причинам отказывает в поставке службы, менеджер пытается связать приложение с другими поставщиками. Если имеется несколько удаленных поставщиков, то порядок, в котором производятся попытки установить с ними связь (т.е. кто получит связь первым), не определен.