При рассмотрении базовой для QNX (собственно, для всех микроядерных ОС) техники обмена сообщениями в сравнении с технологией написания менеджеров ресурсов не покидает ощущение поразительной схожести происходящих в обоих случаях процессов. В этом нет ничего удивительного, поскольку инструментарий менеджеров ресурсов — это только система внешних «оберток» над базовым механизмом обмена сообщениями.

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

 

Простота и трудоемкость

Механизм прямого обмена сообщениями крайне просто выражается в программном коде. Когда достигнута полная ясность в значениях адресных параметров обмена, необходимо всего лишь несколько операторов, чтобы заставить все это «крутиться».

Со стороны сервера, например, это выглядит так:

int chid = ChannelCreate(0);

...

while (true) {

 struct _msg_info info;

 int rcvid = MsgReceive(chid, &bufin, sizeof(bufin), &info);

 if (rcvid < 0) exit(EXIT_FAILURE);

 if (MsgReply(rcvid, EOK, &bufou, sizeof(bufou) < 0) exit(EXIT_FAILURE);

}

Co стороны клиента:

int coid = ConnectAttach(node, pid, chid, _NTO_SIDE_CHANNEL, 0);

if (coid < 0) exit(EXIT_FAILURE);

...

while(...)

 if (MsgSend(coid, &bufou, sizeof(bufou), &bufin, sizeof(bufin)) == -1)

  exit(EXIT_FAILURE);

}

Код для реализации того же обмена, но организованного как менеджер ресурса, будет как минимум в несколько раз объемнее (образцы менеджеров мы уже видели ранее по тексту). Кроме того, по большей части он будет состоять из заполнения полей некоторых внутренних структур, используемых библиотеками менеджера ресурсов или пула потоков. На первый поверхностный взгляд такой код маловразумителен.

С другой стороны, весь достаточно объемный код любого менеджера ресурса — это очередное повторение одного и того же общего шаблона для написания менеджеров. При некоторых минимальных навыках написание самых замысловатых менеджеров ресурсов становится совершенно рутинным занятием, не превышающим по трудоемкости написание простого обмена сообщениями. Большим подспорьем здесь является наличие в комплекте технической документации QNX огромного (более 80 страниц) раздела, исчерпывающе описывающего технику создания менеджеров ресурсов; по качеству и скрупулезности изложения это одна из лучших частей всей технической документации.

 

Гибкость и мобильность

При установлении соединения техника простого обмена сообщениями в качестве адресата сообщений (сервера) использует «магическую тройку» (триплет [1]) параметров ND, PID и CHID, где:

• ND — дескриптор сетевого узла, на котором работает интересующая нас программа-сервер (узел, на который надо отсылать сообщение);

• PID — PID процесса этой программы на своем сетевом узле (кому отсылать сообщение);

• CHID — номер канала, который открыла эта программа для приема сообщений данного вида.

В этой адресации, пожалуй, и кроется самая главная причина негибкости механизма обмена сообщениями. Дескриптор сетевого узла nd, значение которого, кроме того, способно самопроизвольно изменяться в сети с течением времени, мы можем установить по сетевому имени интересующего нас хоста, используя netmgr_strtond(). (Это действие по своей сути избыточное, дополнительный уровень косвенности, так как первичным идентификатором узла для пользователя приложения является его имя, а не дескриптор.)

Гораздо хуже дело обстоит с pid и chid, особенно для процесса, выполняющегося на удаленном сетевом узле. Не существует в общем виде прямого способа установить PID удаленного процесса, а тем более номер канала, который открыл этот процесс для обмена (или вообще не открывал, если мы, например, ошиблись в определении его PID). И тогда на помощь приходят некоторые искусственные приемы, построенные либо на использовании некоторых иерархических (родительский-дочерний) соотношений процессов клиента и сервера, либо на системах совершенно условных договоренностей (произвольных и варьирующихся от случая к случаю).

Р. Кертен [1] отмечает, что существует множество способов нахождения этой адресной триады, и перечисляет некоторые из них:

1. Открыть файл с известным именем и сохранить в нем ND/PID/CHID…

2. Использовать для объявления идентификаторов ND/PID/CHID глобальные переменные программы…

3. Занять часть пространства имен путей и стать администратором ресурсов.

Не вдаваясь в подробный анализ (вы это можете сделать сами), отметим, что 1-й способ — крайне искусственный и негибкий (особенно в сетевой среде), 2-й — крайне ограничен и применим лишь к узкому кругу задач, а 3-й способ подводит нас к применению совсем другой, альтернативной технологии с используемыми ею принципами адресации.

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

Пользуясь случаем, внесем и мы свою лепту в «копилку» способов вычисления адресной триады и увязывания клиента с соответствующим сервером. В тех нечастых случаях, когда требуется обеспечить максимально возможную плотность потока обмена (об этом см. далее), а информационный канал желательно создать на базе именно прямого обмена сообщениями, мы предлагаем оформлять серверный процесс одновременно и как специальный менеджер ресурса, и как канал прямого обмена сообщениями. При этом клиент, пользуясь адресацией пути к менеджеру, запрашивает его по read() или devctl(), на которые менеджер возвращает свой PID и открытый для прямого обмена дополнительный CHID. На этом функции менеджера заканчиваются, а весь информационный обмен далее идет обменом сообщений через указанный канал. Полный текст такого сервера будет показан в примере позже.

Теперь обратимся к технологии менеджера ресурсов. В этой технике менеджер регистрирует в пространстве имен (в файловой системе) уникальное имя, по которому клиенты, заинтересованные в его ресурсе, будут адресоваться к менеджеру. Идея не нова для мира UNIX (каталоги файловой системы /proc или /dev, как правило, вообще не содержат реальных файлов), и она находит все более последовательное расширение в новых разработках операционных систем, отталкивающихся от UNIX, например Plan9 или Inferno.

Техника менеджера ресурса вводит дополнительный уровень разрешения имен, который реализуется через менеджер процессов procnto (как это происходит, подробно и на примерах описывается в [1]). Происходящее при выполнении POSIX-оператора:

int fd = open("/net/host/dev/srv", O_RDONLY);

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

int coid = ConnectAttach(node, pid, chid, 0, 0);

и может даже при определенных обстоятельствах возвратить то же значение и уж по крайней мере всегда возвращает значение той же природы, хотя мы и говорим по привычке в первом случае «файловый дескриптор», а во втором - «идентификатор соединения». Здесь отчетливо видна подмена адресной триады node, pid и chid именем пути /net/host/dev/srv.

Модель адресации менеджера ресурса в QNX, конечно, намного более универсальна, гибка и мобильна, нежели модель прямого обмена сообщениями. Например, можно написать сервер, который при запуске воспринимал бы полное имя, под которым он будет регистрироваться в пространстве имен, например (пусть даже некоторые варианты и сомнительны в своей осмысленности):

# server -n /dev/srv

# server -n /proc/srv

# server -n /fs/srv

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

# server -n /dev/srv1

# server -n /dev/srv2

Наконец, можно сделать это не только на своем локальном узле сети, но и на других сетевых узлах:

# on -f host1 server -n /dev/srv1

# on -f host1 server -n /dev/srv2

# on -f host2 server -n /dev/srv1

# on -f host2 server -n /dev/srv1

Теперь, если наш клиент выполнен так, что позволяет при запуске указать имя сервера, который он должен использовать, мы можем применить такой клиент для работы с самыми различными экземплярами серверов, где бы они ни находились в сети, например:

# client -s /dev/srv1

# client -s /net/host2/dev/srv1

Полный исходный код такой реализации будет показан в примере, к рассмотрению которого мы перейдем после завершения этого раздела.

В чем еще состоит различие, которое можно отнести к категории гибкости механизмов?

В краткой схеме, показанной кодом предыдущего раздела, вызовом:

MsgSend(coid, &bufou, sizeof(bufou), &bufin, sizeof(bufin));

может быть послано сообщение произвольной (в пределах абсолютных ограничений) длины (sizeof(bufou)). Это сообщение (с информацией о его фактической длине) будет принято сервером, который в свою очередь может ответить сообщением произвольной длины, которое и будет доставлено клиенту в ответ на оператор MsgSend().

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

1. Команды группы read() могут передать в направлении сервера только код команды, уточненный параметрами (например, длина запрашиваемых данных), но не данные. В ответ сервер может передать клиенту данные произвольной длины. Обмен данными однонаправленный, в направлении от сервера к клиенту.

2. Команды группы write() могут передать от клиента к серверу данные произвольной длины, но в ответ сервер может возвратить только код результата - число байт, фактически успешно полученных в результате операции. Обмен данными однонаправленный, в направлении от клиенту к серверу.

3. Команда devctl(), использующаяся обычно для организации канала управления (но это не обязательно), в зависимости от кода команды может передавать данные либо к серверу (подобно write()), либо от сервера (подобно read()), либо в обоих направлениях за один обмен. Таким образом, этой командой может быть организован двунаправленный обмен. Вообще говоря, принято считать, что по devctl() передаются данные фиксированной длины: длина передаваемого блока данных определяется непосредственно кодом команды. Но это не является серьезным ограничением: мы можем динамически формировать код команды перед обменом исходя из объема данных, подлежащих передаче (как это будет показано в примере следующего раздела). Такой трюк позволяет организовать обмен данными произвольной длины. Ограничение здесь состоит в другом: объемы данных, передаваемые по devctl() в обоих направлениях, должны быть равны! А это, согласитесь, не совсем то, что мы видели при простом обмене сообщениями.

4. Наконец, последним вариантом обмена с менеджером ресурса является обмен «сырыми», неформатированными сообщениями. Но это уже вариация простого обмена сообщениями, а как ее реализовать в коде, показано в приложении В. Зайцева.

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

 

Эффективность реализации

Если техника менеджеров ресурсов — это только надстройка над базовым механизмом обмена сообщениями, то возникает совершенно естественный вопрос: какова же плата за использование этого производительного и «комфортного» механизма?

Для анализа «скоростных» характеристик альтернативных механизмов обмена сообщениями создадим группу приложений (клиентские и сервер, файлы cli.cc, clr.cc и srv.cc), а чтобы отдельно не выписывать определения, используемые приложениями, вынесем их в отдельный файл определений (файл common.h).

Общие определения проекта

const char VERSION[] = "vers. 1.03";

// имя, под которым будет регистрироваться в пространстве

// имен наш тестовый менеджер ресурса

static const char DEVNAME[_POSIX_PATH_MAX] = "/dev/srr";

// "базовая часть" команды devctl(), конкретный код команды будет

// формироваться динамически на основе этой части, но исходя

// из фактической длины блока передаваемых данных

const unsigned int DCMD_CMD = 1,

 DCMD_SRR = _POSIX_DEVDIR_TOFROM + (_DCMD_NET << 8) + DCMD_CMD;

// структура ответов менеджера ресурса по запросу read()

struct result {

 pid_t pid;

 int chid;

 uint64_t cps;

 result(void) {

  pid = getpid();

  // если уж возвращать, то и служебную информацию ;)

  cps = SYSPAGE_ENTRY(qtime)->cycles_per_sec;

 }

}

// завершение с извещением кода причины

inline void exit(const char *msg) {

 cout << '\r';

 perror(msg);

 exit(EXIT_FAILURE);

}

В этой части каких-либо комментариев заслуживает разве что структура result. Наш сервер устроен «наоборот»: информационный обмен данными он осуществляет по запросу devctl(), запрос read() нам «не нужен», и мы используем его только для возврата информации (PID + CHID) об автономном канале обмена сообщениями. Заодно мы передаем в поле cps этой структуры значение тактовой частоты процессора сервера, что позволяет знать, «с кем мы имеем дело» при экспериментах в сети.

Теперь мы вполне готовы написать код сервера. Этот сервер (файл srv.cc), в отличие от традиционных, имеет два независимых канала подключения: как менеджер ресурсов и как сервер простого обмена сообщениями. Как менеджер он по запросу read() возвращает адресные компоненты (PID, CHID) для обмена сообщениями (ND клиент должен восстановить самостоятельно). По запросу devctl(), а также по запросу по автономному каналу обмена сообщениями сервер просто ретранслирует обратно полученный от клиента блок данных (в каком-то смысле по обоим каналам обмена наш сервер является «зеркалом», отражающим данные).

Сервер запросов

result data;

//---------------------------------------------------------

// реализация обработчика read()

static int readfunc(resmgr_context_t *ctp, io_read_t *msg,

 iofunc_ocb_t *ocb) {

 int sts = iofunc_read_verify(ctp, msg, ocb, NULL);

 if (sts != EOK) return sts;

 // возвращать одни и те же статические данные...

 MsgReply(ctp->rcvid, sizeof(result), &data, sizeof(result));

 return _RESMGR_NOREPLY;

}

//---------------------------------------------------------

// реализация обработчика devctl.

static int devctlfunc(resmgr_context_t *ctp, io_devctl_t *msg,

 iofunc_ocb_t *ocb) {

 int sts = iofunc_devctl_default(ctp, msg, ocb);

 if (sts != _RESMGR_DEFAULT) return sts;

 // разбор динамически создаваемого кода devctl(),

 // извлечение из него длины принятого блока

 unsigned int nbytes = (msg->i.dcmd - DCMD_SRR) >> 16;

 msg->o.nbytes = nbytes;

 // и тут же ретрансляция блока назад

 return _RESMGR_PTR(ctp, &msg->i, sizeof(msg->i) + nbytes);

}

//---------------------------------------------------------

// установка однопоточного менеджера, выполняемая

// в отдельном потоке

static void* install(void* data) {

 dispatch_t *dpp;

 if ((dpp = dispatch_create()) == NULL)

  exit("dispatch allocate");

 resmgr_attr_t resmgr_attr;

 memset(&resmgr_attr, 0, sizeof(resmgr_attr));

 resmgr_attr.nparts_max = 1;

 resmgr_attr.msg_max_size = 2048;

 static resmgr_connect_funcs_t connect_funcs;

 static resmgr_io_funcs_t io_funcs;

 iofunc_func_init(_RESMGR_CONNECT_NFUNCS, &connect_funcs,

  _RESMGR_IO_NFUNCS, &io_funcs);

 // определяем обработку, отличную от обработки по умолчанию,

 // только для двух команд: read() & devctl()

 io_funcs.read = &readfunc;

 io_funcs.devctl = &devctlfunc;

 static iofunc_attr_t attr;

 iofunc_attr_init(&attr, S_IFNAM | 0666, 0, 0);

 // связываем менеджер с его префиксным именем

 if (resmgr_attach(dpp, &resmgr_attr, DEVNAME,

  _FTYPE_ANY, 0, &connect_funcs, &io_funcs, &attr) == -1)

  exit("prefix attach");

 dispatch_context_t* ctp = dispatch_context_alloc(dpp);

 while (true) {

  if ((ctp = dispatch_block(ctp)) == NULL)

   exit("block error");

  dispatch_handler(ctp);

 }

}

// размер буфера для обмена сообщениями,

// этого нам хватит с большим запасом и надолго ;)

const int blk = 100000;

// обработчик низкоуровневых сообщений,

// также работающий в отдельном потоке

void* msginout(void* с) {

 static uint8_t bufin[blk];

 struct _msg_info info;

 while (true) {

  int rcvid = MsgReceive(data chid, &bufin, blk, &info);

  if (rcvid < 0) exit("message receive");

  if (MsgReply(rcvid, EOK, &bufin, info.msglen) < 0)

  exit("message reply");

 }

}

//--------------------------------------------------------

// "пустой" обработчик реакции на ^C (сигнал SIGINT)

inline static void empty(int signo) {}

//--------------------------------------------------------

// главная программа, которая все это "хозяйство" установит

// и будет безропотно ждать завершения по ^C ;)

int main(int argc, char *argv[]) {

 cout << "SRR server: " << VERSION << endl;

 // открывается менеджер ресурса ...

 int fd = open(DEVNAME, O_RDONLY);

 // если менеджер открылся, то это нам не нужно -

 // дубликаты не создавать!

 if (fd > 0)

  close(fd), cout << "already in use " << DEVNAME << endl, exit(EXIT_FAILURE);

 // перехватываем реакцию ^C:

 cout << ". . . . . . waiting ^C. . . . . ." << flush;

 signal(SIGINT, empty);

 // создается канал для обмена низкоуровневыми сообщениями

 data.chid = ChannelCreate(0);

 // и запускается отдельным потоком ретранслятор с этого канала

 if (pthread_create(NULL, NULL, msginout, NULL) != EOK)

  exit("message thread");

 // запускается менеджер ресурса

 if (pthread_create(NULL, NULL, install, NULL) != EOK)

  exit("manager thread");

 // ... все! Мы свое дело сделали и ожидаем ^C ...

 pause();

 cout << "\rFinalization... " << endl;

 // ... очистка, завершение ...

 ChannelDestroy(data.chid);

 return EXIT_SUCCESS;

}

Первая клиентская программа (файл cli.cc) посылает серверу блок данных указанной длины (длина может изменяться в широких пределах указанием при запуске ключа -b) и ожидает от него ретрансляции, после чего замеряет время ответа от сервера. Этот процесс повторяется многократно (ключ -m).

Первый клиентский процесс

#include "common.h"

static uint64_t *tim;

static int num = 10;

// вывод результатов с оценкой статистики: среднее, С.К.О...

static void outtim(void) {

 double m = 0., s = 0.;

 for (int i = 0; i < num; i++) {

  double d = (double)tim[i];

  m += d;

  s += d * d;

 }

 m /= num;

 s = sqrt(s / num - m * m);

 cout << '\t' << (uint64_t)floor(m + 5) << "\t~" << (uint64_t)floor(s + .5) <<

  "\t{" << (uint64_t)floor(s / m * 100 + .5) << "%}" << endl;

}

int main(int argc, char **argv) {

 cout << "SRR client: " << VERSION << endl;

 int opt, val;

 unsigned int blk = 100;

 char PATH[_POSIX_PATH_MAX] = "";

 while ((opt = getopt(argc, argv, "n:b:m:")) != -1) {

  switch (opt) {

  case 'n': // имя хоста сервера

   strcpy(PATH, "/net/");

   strcat(PATH, optarg);

   break;

  case 'b': // размер блока обмена (байт)

   if (sscanf(optarg, "%i", &blk) != 1)

    exit("parse command line failed");

   break;

  case 'm': // число повторений таких блоков

   if (sscanf(optarg, "%i", &num) != 1)

    exit("parse command line failed");

   break;

  default:

   exit(EXIT_FAILURE);

  }

 }

 // "составить" полное имя менеджера

 strcat(PATH, DEVNAME);

 cout << "server path. " << PATH << ", block size = "

  << blk << " bytes, repeat = " << num << endl;

 // при инициализации мы сразу получаем скорость процессора клиента

 result data;

 cout << "CPU speed [с.p.s ]: client = " << data.cps;

 // пытаемся подключиться к серверу-менеджеру

 int fd = open(PATH, O_RDONLY);

 if (fd < 0) exit("server not found");

 // читаем его параметры

 if (read(fd, &data, sizeof(result)) == -1)

  exit("parameter block read");

 cout << ", server = " << data.cps << endl;

 tim = new uint64_t[num];

 uint64_t tim2;

 uint8_t *bufin = new uint8_t[blk];

 *bufou = new uint8_t[blk];

 // определяем дескриптор сетевого узла

 int32_t node = netmgr_strtond(PATH, NULL);

 // это интересное место: если в имени нет сетевого префикса пути,

 // но это имя удается открыть, то это локальный хост!

 if (node == -1 && fd > 0 && errno == ENOENT)

  node = ND_LOCAL_NODE;

 // по адресным данным, полученным ранее по read(), создаем канал

 // для прямого обмена сообщениями с тем же процессом:

 int coid = ConnectAttach(node, data.pid, data.chid, _NTO_SIDE_CHANNEL, 0);

 if (coid < 0) exit("connect to message channel");

 cout << " - message exchange:" << flush;

 // обмен по каналу низкоуровневых сообщений

 for (int i = 0; i < num; i++) {

  tim[i] = ClockCycles();

  if (MsgSend(coid, bufou, blk, bufin, blk) == -1)

   exit("exchange data with channel");

  tim[i] = ClockCycles() - tim[i];

 }

 outtim();

 ConnectDetach(coid);

 // повторяем в точности тот же обмен, но по запросу devctl()

 unsigned int DCTL = (blk<<16) + DCMD_SRR;

 cout << "- manager exchange:" << flush;

 for (int i = 0; i < num; i++) {

  tim[i] = ClockCycles();

  if (devctl(fd, DCTL, bufou, blk, NULL) ! = EOK)

   exit("DEVCTL error");

  tim[i] = ClockCycles() - tim[i];

 }

 outtim();

 close(fd);

 delete [] bufin;

 delete [] bufou;

 delete [] tim;

 return EXIT_SUCCESS;

}

Смотрим локальные результаты исполнения и оценки, которые дает нам эта клиентская программа (знаком отмечено С.К.О. предшествующего ему в выводе значения измеренной средней величины, после чего в скобках — процентное отношение этого С.К.О. к измеряемой величине):

# nice -n-19 cli -b1 -m1000

SRR client: vers. 1.03

server path: /dev/srr, block size = 1 bytes, repeat = 1000

CPU speed [c.p.s.]: client = 534639500, server = 534639500

- message exchange: 2693 ~168 {6%}

- manager exchange: 6579 ~357 {5%}

# nice -n-19 cli -b10 -m1000

SRR client: vers. 1.03

server path: /dev/srr, block size = 10 bytes, repeat = 1000

CPU speed [c.p.s.]: client = 534639500, server = 534639500

- message exchange: 2726 ~258 {9%}

- manager exchange: 6725 ~378 {6%}

# nice -n-19 cli -b100 -m1000

SRR client: vers. 1.03

server path: /dev/srr, block size = 100 bytes, repeat = 1000

CPU speed [c.p.s.]: client = 534639500, server = 534639500

- message exchange: 3351 ~190 {6%}

- manager exchange: 7055 ~414 {6%}

# nice -n-19 cli -b1000 -m1000

SRR client: vers 1.03

server path: /dev/srr, block size = 1000 bytes, repeat = 1000

CPU speed [c.p.s.]: client = 534639500, server = 534639500

- message exchange: 3912 ~369  {9%}

- manager exchange: 8312 ~4024 {48%}

# nice -n-19 cli -b4000 -m1000

SRR client: vers 1.03

server path: /dev/srr, block size = 4000 bytes, repeat = 1000

CPU speed [c.p.s.] client = 534639500, server = 534639500

- message exchange: 5393  ~518 {10%}

- manager exchange: 10666 ~770 {7%}

# nice -n-19 cli -b6000 -m1000

SRR client vers 1.03

server path /dev/srr, block size = 6000 bytes, repeat = 1000

CPU speed [c.p.s.]: client = 534639500, server = 534639500

- message exchange: 7373  ~612 {8%}

- manager exchange: 12423 ~995 {8%}

# nice -n-19 cli -b1000 -m1000

SRR client: vers. 1.03

server path /dev/srr, block size = 10000 bytes, repeat = 1000

CPU speed [c.p.s.]: client = 534639500, server = 534639500

- message exchange: 14365 ~953  {7%}

- manager exchange: 16018 ~5399 {34%}

Это дает нам следующую информацию:

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

• Обмен в эквивалентных условиях с сервером, работающим как менеджер ресурса, требует (в сравнении с прямым обменом сообщениями) в 1,12–2,44 раз большее количество процессорных циклов на свое обслуживание, или, в относительных единицах, максимально достижимая производительность менеджера меньше на 12–144% .

• Самые неблагоприятные (144%) значения относятся к случаю обмена короткими сообщениями (1–10 байт); достаточно ощутимое (~2) значение этого соотношения сохраняется до размеров передаваемых блоков данных, равных 8–10 Кбайт.

• Накладные расходы на передачу единичного байта информации недопустимо велики (2693 циклов на байт при обмене сообщениями и 6579 циклов на байт — для менеджера) при организации обмена короткими сообщениями. С ростом объема данных, передаваемых за один цикл обмена, этот показатель очень резко падает (на блоках по 100 байт уже 33,5 и 70 соответственно, т.е. 2 порядка). Для систем с интенсивными потоками обмена необходимо стремиться максимально блокировать передаваемые данные и минимизировать число актов обмена.

Теперь выполним то же самое, но при обмене с сервером, локализованным на удаленном хосте сети (мы используем низкоскоростную сеть 10 Мбит/сек, на которой все эффекты более наглядны):

# nice -n-19 cli -nrtp -b1 -m500

SRR client: vers. 1.03

server path: /net/rtp/dev/srr, block size = 1 bytes, repeat = 500

CPU speed [c.p.s.]: client = 534639500, server = 451163200

- message exchange: 671017 ~391587 {58%}

- manager exchange: 712181 ~394844 {55%}

# nice -n-19 cli -nrtp -b10 -m500

SRR client: vers. 1.03

server path: /net/rtp/dev/srr, block size = 10 bytes, repeat = 500

CPU speed [c.p.s.]: client = 534639500, server = 451163200

- message exchange: 642456 ~380313 {59%}

- manager exchange: 743094 ~423717 {57%}

# nice -n-19 cli -nrtp -b100 -m500

SRR client: vers. 1.03

server path: /net/rtp/dev/srr, block size = 100 bytes, repeat = 500

CPU speed [c.p.s.]: client = 534639500, server = 451163200

- message exchange: 878686 ~432230 {49%}

- manager exchange: 907474 ~420140 {46%}

# nice -n-19 cli -nrtp -b1000 -m500

SRR client: vers. 1.03

server path: /net/rtp/dev/srr, block size = 1000 bytes, repeat = 500

CPU speed [c.p.s.]: client = 534639500, server = 451163200

- message exchange: 2064542 ~358333 {17%}

- manager exchange: 2113638 ~372487 {18%}

# nice -n-19 cli -nrtp -b3000 -m200

SRR client: vers. 1.03

server path: /net/rtp/dev/srr, block size = 3000 bytes, repeat = 200

CPU speed [c.p.s.]: client = 534639500, server = 451163200

- message exchange: 4134249 ~418168 {10%}

- manager exchange: 4181481 ~418139 {10%}

# nice -n-19 cli -nrtp -b5000 -m200

SRR client: vers. 1.03

server path: /net/rtp/dev/srr, block size = 5000 bytes, repeat = 200

CPU speed [c.p.s.]: client = 534639500, server = 451163200

- message exchange: 5805056 ~252663 {4%}

- manager exchange: 5825837 ~229120 {4%}

# nice -n-19 cli -nrtp -b8000 -m200

SRR client: vers. 1.03

server path /net/rtp/dev/srr, block size = 8000 bytes, repeat = 200

CPU speed [c.p.s.]: client = 534639500, server = 451163200

- message exchange: 8741090 ~446299 {5%}

- manager exchange: 8788642 ~427459 {5%}

# nice -n-19 cli -nrtp -b10000 -m200

SRR client: vers. 1.03

server path: /net/rtp/dev/srr, block size = 10000 bytes, repeat = 200

CPU speed [c.p.s.]: client = 534639500, server = 451163200

- message exchange: 8971296 ~451857 {5%}

- manager exchange: 9731224 ~301409 {3%}

В этом варианте основной компонент задержки вносится передачей данных по физическому каналу; разница между реализациями обмена сообщениями и менеджера ресурсов в значительной степени нивелирована.

Наш второй клиент (файл clr.cc), неизменно работающий с тем же сервером, весьма похож на предыдущий, но он массированно «гонит» поток данных на сервер, пользуясь только одним из механизмов (ключ -d) до прекращения его выполнения пользователем по ^C. Результат его работы — средняя плотность потока информации за весь интервал работы.

Второй клиентский процесс

#include "common.h"

static bool conti = true;

// завершение процесса по сигналу пользователя (SIGINT - ^C)

inline static void trap(int signo) { conti = false; }

int main(int argc, char **argv) {

 cout << "SRR repeater: " << VERSION << endl;

 int opt, val;

 unsigned int blk = 100;

 char PATH[_POSIX_PATH_MAX] = "";

 bool lowlvl = true;

 while ((opt = getopt(argc, argv, "n:b:d")) != -1) {

  switch(opt) {

  case 'n': // имя сетевого узла

   strcpy(PATH, "/net/");

   strcat(PATH, optarg);

   break;

  case 'b': // размер блока данных

   if (sscanf(optarg, "%i", &blk) ! = 1)

    exit("parse command line failed");

   break;

  case 'd': // обмен сообщениями

   lowlvl = false;

   break;

  default:

   exit(EXIT_FAILURE);

  }

 }

 strcat(PATH, DEVNAME);

 cout << "server path: " << PATH

  << ", block size = " << blk << " bytes" << endl;

 // при инициализации мы сразу получаем скорость процессора клиента

 result data;

 cout << "CPU speed [c.p.s.]: client = " << data.cps;

 uint64_t cps = data.cps;

 // пытаемся подключиться к серверу-менеджеру

 int fd = open(PATH, O_RDONLY);

 if (fd < 0) exit("server not found");

 // читаем его параметры

 if (read(fd, &data, sizeof(result)) == -1)

  exit("parameter block read");

 cout << ", server = " << data.cps << endl;

 // определяем дескриптор сетевого узла

 int32_t node = netmgr_strtond(PATH, NULL);

 if (node == -1 && fd > 0 && errno == ENOENT)

  node = ND_LOCAL_NODE;

 // по адресным данным, полученным ранее по read(), создаем

 // канал для прямого обмена сообщениями с тем же процессом

 int coid = ConnectAttach(node, data.pid, data.chid, _NTO_SIDE_CHANNEL, 0);

 if (coid < 0) exit("connect to message channel");

 // динамически готовим код команды devctl():

 unsigned int DCTL = (blk << 16) + DCMD_SRR;

 cout << " . . . . . waiting ^C . . . . . " << flush;

 // устанавливается реакция на пользовательский ^C

 signal(SIGINT, trap);

 uint64_t num = 0;

 uint8_t *bufin = new uint8_t[blk], *bufou = new uint8_t[blk];

 uint64_t tim = ClockCycles();

 // в зависимости от выбранного механизма передаем с его помощью данные

 if (lowlvl)

  while (true) {

   if (MsgSend(coid, bufou, blk, bufin, blk) == -1)

    exit("exchange data with channel");

   num++;

   if (!conti) break;

  }

 else {

  while (true) {

   if (devctl(fd, DCTL, bufou, blk, NULL) != EOK)

    exit("DEVCTL error");

   num++;

   if (!conti) break;

  }

 }

 tim = ClockCycles() - tim;

 cout << '\r' << (lowlvl ? "message exchange:" : "manager exchange:") <<

  " number = " << num << "; stream = "

  << (double)num * blk / ((double)tim / (double)cps) / 1E6 * 8 <<

  " Mbit/sec" << endl;

 ConnectDetach(coid);

 close(fd);

 delete [] bufin;

 delete [] bufou;

 return EXIT_SUCCESS;

}

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

# clr -b1

SRR repeater: vers. 1.03

server path: /dev/srr, block size = 1 bytes

CPU speed [c.p.s.]: client = 534639500, server = 534639500

message exchange: number = 906400; stream = 1.54088 Mbit/sec

# clr -b1 -d

SRR repeater: vers. 1.03

server path: /dev/srr, block size = 1

bytes CPU speed [c.p.s.]: client = 534639500, server = 534639500

manager exchange, number = 335725; stream = 0.617311 Mbit/sec

# clr -b10

SRR repeater: vers. 1.03

server path: /dev/srr, block size = 10 bytes

CPU speed [c.p.s.]: client = 534639500, server = 534639500

message exchange: number = 1119211; stream = 15.0758 Mbit/sec

# clr -bl0 -d

SRR repeater: vers. 1.03

server path: /dev/srr, block size = 10 bytes

CPU speed [c.p.s.]: client = 534639500, server = 534639500

manager exchange: number = 316948; stream = 6.1421 Mbit/sec

# clr -b100

SRR repeater: vers. 1.03

server path: /dev/srr, block size = 100 bytes

CPU speed [c.p.s.]: client = 534639500, server = 534639500

message exchange: number = 729460; stream = 122.617 Mbit/sec

# clr -b100 -d

SRR repeater: vers. 1.03

server path: /dev/srr, block size = 100 bytes

CPU speed [c.p.s.]: client = 534639500, server = 534639500

manager exchange: number = 318435, stream = 57.3215 Mbit/sec

# clr -b1000

SRR repeater: vers. 1.03

server path: /dev/srr, block size = 1000 bytes

CPU speed [с.p.s.]: client = 534639500, server = 534639500

message exchange: number = 823535; stream = 1054.65 Mbit/sec

# clr -b1000 -d

SRR repeater: vers. 1.03

server path: /dev/srr, block size = 1000 bytes

CPU speed [c.p.s.]: client = 534639500, server = 534639500

manager exchange: number = 367712; stream = 493.455 Mbit/sec

# clr -b10000

SRR repeater: vers. 1 03

server path: /dev/srr, block size = 10000 bytes

CPU speed [c.p.s.]: client = 534639500, server = 534639500

message exchange number = 196479, stream = 2861.27 Mbit/sec

# clr -b10000 -d

SRR repeater: vers. 1.03

server path: /dev/srr, block size = 10000 bytes

CPU speed [c.p.s.]: client = 534639500, server = 534639500

manager exchange: number = 141593, stream = 2487.18 Mbit/sec

Цифры достаточно интересные, для того чтобы рассмотреть их детальнее:

• При непрерывном потоке обмена очень короткими сообщениями (1 байт) плотность информационного потока падает до смехотворно низкой величины — 192 Кбайт/сек для обмена сообщениями и 77 Кбайт/сек для обмена с менеджером ресурса.

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

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

Естественно, поскольку мы рассматриваем чисто программные реализации обмена, абсолютные численные значения будут прямо пропорционально зависеть от скорости процессора (представленные результаты соответствуют процессору 533 МГц). На рис. 5.2 показана динамика загрузки процессора при работе тестовых приложений для случая локального размещения клиента и сервера. Хорошо видно, что в периоды выполнения программы clr загрузка процессора подскакивает до 100% — совместной активностью клиент и сервер забирают весь ресурс процессора.

Рис. 5.2. Динамика загрузки процессора при локальном взаимодействии клиента с сервером

Далее посмотрим выполнение той же пары приложений, но уже при разнесении их между раздельными узлами сети:

# clr -nrtp -b1

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 1 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

message exchange: number = 5049, stream = 0.00670981 Mbit/sec

# clr -nrtp -b1 -d

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 1 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

manager exchange: number = 4824; stream = 0.00598806 Mbit/sec

# clr -nrtp -b10

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 10 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

message exchange number = 3885; stream = 0.0651842 Mbit/sec

# clr -nrtp -b10 -d

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 10 bytes

CPU speed [c.p.s ]: client = 534639500, server = 451163200

manager exchange: number = 3102, stream = 0.0557978 Mbit/sec

# clr -nrtp -b100

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 100 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

message exchange: number = 3347, stream = 0.507917 Mbit/sec

При взаимодействии клиента с сервером по сети в тех же условиях, что и на рис. 5.2, клиент уже не загружает процессор более чем на 50% (рис. 5.3). Если организовать обмен клиента с сервером в несколько потоков (2-3), то при максимальной загрузке процессора можно увеличить плотность потока еще вдвое.

Рис. 5.3. Загрузка процессора клиента при сетевом взаимодействии клиента с сервером

# clr -nrtp -b100 -d

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 100 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

manager exchange: number = 2167; stream = 0.480264 Mbit/sec

# clr -nrtp -b1000

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 1000 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

message exchange: number = 1400; stream = 2.0555 Mbit/sec

# clr -nrtp -b1000 -d

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 1000 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

manager exchange: number = 1626; stream = 2.00553 Mbit/sec

# clr -nrtp -b10000

SRR repeater: vers. 1.03

server path: /net/rtp/dev/srr, block size = 10000 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

message exchange: number = 366; stream = 4.73793 Mbit/sec

# clr -nrtp -b10000 -d

SRR repeater: vers 1.03

server path: /net/rtp/dev/srr, block size = 10000 bytes

CPU speed [c.p.s.]: client = 534639500, server = 451163200

manager exchange: number = 440; stream = 4.39515 Mbit/sec

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

Обратите внимание, что при больших блоках передаваемых данных (10 Кбайт) скорость информационного канала (4.395–4.738*2, учитывая что ретрансляция ведется в двух направлениях) сильно приближается к физической пропускной способности канала (10 Мбит/сек, как уже отмечалось выше), что попутно говорит о весьма высокой эффективности реализации обмена протоколами сети QNET.

 

Что же в итоге?

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

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