Теперь мы поменяем протоколы, используемые клиентом и сервером в примере из предыдущего раздела. Сначала рассмотрим TCP-клиент IPv6, запущенный на узле с двойным стеком протоколов.

1. Сервер IPv4 запускается на узле, поддерживающем только IPv4, и создает прослушиваемый сокет IPv4.

2. Запускается клиент IPv6 и вызывает функцию gethostbyname, запрашивая только адреса IPv6 (запрашивает семейство AF_INET6 и устанавливает флаг AI_V4MAPPED в структуре hints). Поскольку у сервера, поддерживающего только IPv4, есть лишь записи типа А, мы видим, согласно табл. 11.3, что клиенту возвращается адрес IPv4, преобразованный к виду IPv6.

3. Клиент IPv6 вызывает функцию connect с адресом IPv4, преобразованным к виду IPv6, в структуре адреса сокета IPv6. Ядро обнаруживает преобразованный адрес и автоматически посылает серверу сегмент SYN IPv4.

4. Сервер отвечает сегментом SYN/ACK IPv4, и устанавливается соединение, по которому происходит обмен дейтаграммами IPv4. Этот сценарий мы схематически изображаем на рис. 12.3.

Рис. 12.3. Обработка клиентских запросов в зависимости от типа адреса и типа сокета

■ Если TCP-клиент IPv4 вызывает функцию connect, задавая адрес IPv4, или если UDP-клиент IPv4 вызывает функцию sendto, задавая адрес IPv4, ничего особенного не происходит. На рисунке это изображено двумя стрелками, помеченными «IPv4».

■ Если TCP-клиент IPv6 вызывает функцию connect, задавая адрес IPv6, или если UDP-клиент IPv6 вызывает функцию sendto, задавая адрес IPv6, тоже ничего особенного не происходит. На рисунке это показано двумя стрелками, помеченными «IPv6».

■ Если TCP-клиент IPv6 вызывает функцию connect, задавая адрес IPv4, преобразованный к виду IPv6, или если UDP-клиент вызывает функцию sendto, задавая адрес IPv4, преобразованный к виду IPv6, ядро обнаруживает сопоставленный адрес и инициирует отправку дейтаграммы IPv4 вместо дейтаграммы IPv6. На рисунке это показано двумя штриховыми стрелками.

■ Клиент IPv4 не может задать адрес IPv6 ни функции connect, ни функции sendto, поскольку 16-байтовый адрес IPv6 не соответствует 4-байтовой структуре in_addr в структуре IPv4 sockaddr_in. Следовательно, на рисунке нет стрелок от сокетов IPv4 к протоколу IPv6.

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

Резюме: совместимость IPv4 и IPv6

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

Таблица 12.2. Обобщение совместимости клиентов и серверов IPv4 и IPv6

Каждая ячейка этой таблицы содержит поля «IPv4» или «IPv6» с указанием используемого протокола, если данное сочетание работает, либо «нет», если комбинация недопустима. Ячейка в последней строке третьей колонки отмечена звездочкой, поскольку совместимость зависит от адреса, выбранного клиентом. При выборе записи типа AAAA отправка дейтаграммы IPv6 будет невозможна. Но выбор записи типа А, которая возвращается клиенту как адрес IPv4, преобразованный к виду IPv6, приведет к отправке дейтаграммы IPv4. Перебрав все адреса, возвращаемые getaddrinfo, мы обязательно доберемся до адреса IPv4, преобразованного к виду IPv6, пусть даже и потратив некоторое время на безуспешное ожидание.

Хотя четверть из представленных в таблице сочетаний недопустима, в обозримом будущем большинство реализаций IPv6 будут использоваться на узлах с двойным стеком протоколов и поддерживать не только IPv6. Если мы удалим из таблицы вторую строку и вторую колонку, все записи «Нет» исчезнут и единственной проблемой останется запись, помеченная звездочкой.

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

Листинг 13.1. Функция daemon_init: придание процессу свойств демона

//daemon _init.с

 1 #include "unp.h"

 2 #include

 3 #define MAXFD 64

 4 extern int daemon_proc; /* определен в error.с */

 5 int

 6 daemon_init(const char *pname, int facility)

 7 {

 8  int i;

 9  pid_t pid;

10  if ((pid = Fork()) < 0)

11   return (-1);

12  else if (pid)

13   _exit(0); /* родитель завершается */

14  /* 1-й дочерний процесс продолжает работу... */

15  if (setsid() < 0) /* становится главным процессом сеанса */

16   return (-1);

17  Signal(SIGHUP, SIG_IGN);

18  if ((pid = Fork()) < 0)

19   return (-1);

20  else if (pid)

21   _exit(0); /* 1-й дочерний процесс завершается */

22  /* 2-й дочерний процесс продолжает работу */

23  daemon_proc = 1; /* для функций err_XXX() */

24  chdir("/"); /* смена текущего каталога */

25  /* закрытие дескрипторов файлов*/

26  for (i = 0; i < MAXFD; i++)

27   close(i);

28  /* перенаправление stdin, stdout и stderr в /dev/null */

29  open("/dev/null", O_RDONLY);

30  open("/dev/null", O_RDWR);

31  open("/dev/null", O_RDWR);

32  openlog(pname, LOG_PID, facility);

33  return (0); /* успешное завершение */

34 }

Вызов функции fork

10-13 Сначала мы вызываем функцию fork, после чего родительский процесс завершается, а дочерний продолжается. Если процесс был запущен из интерпретатора команд в фоновом режиме, то, когда родительский процесс завершается, оболочка считает, что команда выполнена. Это автоматически запускает дочерний процесс в фоновом режиме. Дочерний процесс наследует идентификатор группы процессов от родительского процесса, но получает свой собственный идентификатор процесса. Это гарантирует, что дочерний процесс не является главным в группе процессов, что требуется для следующего вызова функции setsid.

Вызов функции setsid

15-16 Функция setsid — это функция POSIX, создающая новый сеанс. (В главе 9 [110] подробно рассказывается о взаимоотношениях процессов.) Процесс становится главным в новом сеансе, становится главным в новой группе процессов и не имеет управляющего терминала.

Игнорирование сигнала SIGHUP и новый вызов функции fork

17-21 Мы игнорируем сигнал SIGHUP и снова вызываем функцию fork. Когда эта функция завершается, родительский процесс на самом деле является первым дочерним процессом, и он завершается, оставляя выполняться второй дочерний процесс. Назначение второй функции fork — гарантировать, что демон не сможет автоматически получить управляющий терминал, если потом он откроет устройство терминала. В SVR4, когда главный процесс сеанса без управляющего терминала открывает устройство терминала (которое в этот момент не является управляющим терминалом для другого сеанса), терминал становится управляющим терминалом главного процесса сеанса. Но вызывая второй раз функцию fork, мы гарантируем, что второй дочерний процесс больше не является главным в сеансе, поэтому он не может получить управляющий терминал. Сигнал SIGHUP приходится игнорировать, поскольку, когда главный процесс сеанса завершает работу (первый дочерний процесс), всем процессам в сеансе (нашему второму дочернему процессу) посылается сигнал SIGHUP.

Установка флага для функций ошибок

23 Мы присваиваем глобальной переменной daemon_proc ненулевое значение. Эта внешняя переменная задается нашими функциями err_ XXX (см. раздел Г.4), и ее ненулевое значение сообщает этим функциям, что нужно вызвать функцию syslog вместо функции fprintf (которая выводит сообщение об ошибке в стандартный поток сообщений об ошибках). Это спасает нас от необходимости проходить через весь наш код и вызывать одну из наших функций ошибок, если сервер не работает как демон (то есть когда мы проверяем сервер), а при работе в режиме демона заменять все вызовы на вызовы syslog.

Изменение рабочего каталога и сброс всех битов в маске режима создания файла

24 Мы изменяем рабочий каталог на корневой каталог, хотя у некоторых демонов могут быть причины изменить рабочий каталог на какой-либо другой. Например, демон печати может изменить его на каталог, в котором накапливается содержимое заданий для принтера и происходит вся работа по выводу данных на печать. Если демоном сбрасывается дамп (файл core), он появляется в текущем рабочем каталоге. Другой причиной для изменения рабочего каталога является то, что демон мог быть запущен в любой файловой системе, и если он там останется, эту систему нельзя будет размонтировать, во всяком случае, без жестких мер.

Закрытие всех открытых дескрипторов

25-27 Мы закрываем все открытые дескрипторы, которые наследуются от процесса, запустившего демон (обычно этим процессом бывает интерпретатор команд). Проблема состоит в определении наибольшего используемого дескриптора: в Unix нет ни одной функции, предоставляющей это значение. Есть способы определения максимального числа дескрипторов, которое может открыть процесс, но даже это достаточно сложно [110, с. 43], поскольку предел может быть бесконечным. Наше решение — закрыть первые 64 дескриптора, даже если большинство из них, возможно, не было открыто.

ПРИМЕЧАНИЕ

Solaris предоставляет функцию closefrom, позволяющую демонам решать эту проблему.

Перенаправление stdin, stdout и stderr в /dev/null

29-31 Некоторые демоны открывают /dev/null для чтения и записи и подключают к нему дескрипторы стандартных потоков ввода, вывода и сообщений об ошибках. Это гарантирует, что наиболее типичные дескрипторы открыты и операция чтения из любого из них возвращает 0 (конец файла), а ядро игнорирует все, что записано в любой из этих трех дескрипторов. Причина, по которой требуется открыть эти дескрипторы, заключается в том, что любая библиотечная функция, вызываемая демоном и считающая, что она может читать из стандартного потока ввода или записывать либо в стандартный поток вывода, либо в стандартный поток сообщений об ошибках, не должна завершиться с ошибкой. Отказ был бы потенциально опасен: если демон открывает сокет для связи с клиентом, дескриптор сокета воспринимается как стандартный поток вывода, поэтому ошибочный вызов какой-нибудь функции типа perror может привести к отправке клиенту нежелательных данных.

Использование демона syslogd для вывода сообщений об ошибках

32 Вызывается функция openlog. Первый ее аргумент берется из вызывающего процесса и обычно является именем программы (например, argv[0]). Мы указываем, что идентификатор процесса должен добавляться к каждому сообщению. Аргумент facility также задается вызывающим процессом, и его значением может быть константа из табл. 13.2 либо, если приемлемо значение по умолчанию LOG_USER, нулевое значение.

Отметим, что поскольку демон выполняется без управляющего терминала, он никогда не должен получать сигнал SIGHUP от ядра. Следовательно, многие демоны используют этот сигнал в качестве уведомления от администратора, что файл конфигурации демона изменился и демон должен еще раз считать файл. Два других сигнала, которые демон никогда не должен получать, — это сигналы SIGINT и SIGWINCH, и они также могут использоваться для уведомления демона о некоторых изменениях.

Пример: сервер времени и даты в качестве демона

В листинге 13.2 представлено изменение нашего сервера времени и даты, не зависящего от протокола. В отличие от сервера, показанного в листинге 11.8, в нем вызывается функция daemon_init, чтобы этот сервер мог выполняться в качестве демона.

Листинг 13.2. Не зависящий от протокола сервер времени и даты, работающий в качестве демона

//inetd/daytimetcpsrv2.c

 1 #include "unp.h"

 2 #include

 3 int

 4 main(int argc, char **argv)

 5 {

 6  int listenfd, connfd;

 7  socklen_t addrlen, len;

 8  struct sockaddr *cliaddr;

 9  char buff[MAXLINE];

10  time_t ticks;

11  daemon_init(argv[0], 0);

12  if (argc == 2)

13   listenfd = Tcp_listen(NULL, argv[1], &addrlen);

14  else if (argc == 3)

15   listenfd = Tcp_listen(argv[1], argv[2], &addrlen);

16  else

17   err_quit("usage: daytimetcpsrv2 [ ] ");

18  cliaddr = Malloc(addrlen);

19  for (;;) {

20   len = addrlen;

21   connfd = Accept(listenfd, cliaddr, &len);

22   err_msg("connection from %s", Sock_ntop(cliaddr, len));

23   ticks = time(NULL);

24   snprintf(buff, sizeof(buff), "%.24s\r\n", ctime(&ticks));

25   Write(connfd, buff, strlen(buff));

26   Close(connfd);

27  }

28 }

Изменений всего два: мы вызываем нашу функцию daemon_init, как только программа запускается, а затем вызываем нашу функцию err_msg вместо printf, чтобы вывести IP-адрес и порт клиента. На самом деле, если мы хотим, чтобы наши программы могли выполняться как демоны, мы должны исключить вызов функций printf и fprintf и вместо них использовать нашу функцию err_msg.

Обратите внимание, что мы проверяем argc и выводим соответствующее сообщение до вызова daemon_init. Таким образом пользователь, запустивший демона, получает немедленное уведомление о недопустимом количестве аргументов. После вызова daemon_init все сообщения направляются в системный журнал.

Если мы запустим эту программу на нашем узле linux и затем проверим файл /var/log/messages (куда мы отправляем все сообщения LOG_USER) после соединения с тем же узлом, мы получим:

Jul 10 09:54:37 linux daytimetcpsrv2[24288]: connection from 127.0.0.1.55862

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

В листинге 13.3 показана функция daemon_inetd, которую мы можем вызвать с сервера, запущенного демоном inetd.

Листинг 13.3. Функция daemon_inetd для придания свойств демона процессу, запущенному демоном inetd

//daemon_inetd.c

1 #include "unp.h"

2 #include

3 extern int daemon_proc; /* определено в error.c */

4 void

5 daemon_inetd(const char *pname, int facility)

6 {

7  daemon_proc = 1; /* для наших функций err_XXX() */

8  openlog(pname, LOG_PID, facility);

9 }

Эта функция тривиальна по сравнению с daemon_init, потому что все шаги выполняются демоном inetd при запуске. Все, что мы делаем, — устанавливаем флаг daemon_proc для наших функций ошибок (см. табл. Г.1) и вызываем функцию openlog с теми же аргументами, что и при вызове функции daemon_init, представленной в листинге 13.1.

Пример: сервер времени и даты, активизированный демоном inetd

Листинг 13.4 представляет собой модификацию нашего сервера времени и даты, показанного в листинге 13.2, который может быть активизирован демоном inetd.

Листинг 13.4. Не зависящий от протокола сервер времени и даты, который может быть активизирован демоном inetd

//inetd/daytimetcpsrv3.c

 1 #include "unp.h"

 2 #include

 3 int

 4 main(int argc, char **argv)

 5 {

 6  socklen_t len;

 7  struct sockaddr *cliaddr;

 8  char buff[MAXLINE];

 9  time_t ticks;

10  daemon_inetd(argv[0], 0);

11  cliaddr = Malloc(MAXSOCKADDR);

12  len = MAXSOCKADDR;

13  Getpeername(0, cliaddr, &len);

14  err_msg("connection from %s", Sock_ntop(cliaddr, len));

15  ticks = time(NULL);

16  snprintf(buff, sizeof(buff), "%.24s\r\n\", ctime(&ticks));

17  Write(0, buff, strlen(buff));

18  Close(0); /* закрываем соединение TCP */

19  exit(0);

20 }

В программе сделано два важных изменения. Во-первых, исчез весь код создания сокета: вызовы функций tcp_listen и accept. Эти шаги выполняются демоном inetd, и мы ссылаемся на соединение TCP, используя нулевой дескриптор (стандартный поток ввода). Во-вторых, исчез бесконечный цикл for, поскольку сервер активизируется по одному разу для каждого клиентского соединения. После предоставления сервиса клиенту сервер завершает свою работу.

Вызов функции getpeername

11-14 Поскольку мы не вызываем функцию tcp_listen, мы не знаем размера структуры адреса сокета, которую она возвращает, а поскольку мы не вызываем функцию accept, то не знаем и адреса протокола клиента. Следовательно, мы выделяем буфер для структуры адреса сокета, используя нашу константу MAXSOCKADDR и вызываем функцию getpeername с нулевым дескриптором в качестве первого аргумента.

Чтобы выполнить этот пример в нашей системе Solaris, сначала мы присваиваем службе имя и порт, добавляя следующую строку в /etc/services:

mydaytime 9999/tcp

Затем добавляем строку в /etc/inetd.conf:

mydaytime stream tcp nowait andy

/home/andy/daytimetcpsrv3 daytimetcpsrv3

(Мы разбили длинную строку на более короткие.) Мы помещаем выполняемый код в заданный файл и отправляем демону inetd сигнал SIGHUP, сообщающий ему, что нужно заново считать файл конфигурации. Следующий шаг — выполнить программу netstat, чтобы проверить, что на порте TCP 9999 создан прослушиваемый сокет:

solaris % netstat -na | grep 9999

*.9999 *.* 0 0 49152 0 LISTEN

Затем мы запускаем сервер с другого узла:

linux % telnet solaris 9999

Trying 192.168.1.20...

Connected to solaris.

Escape character is '^]'.

Tue Jun 10 11:04:02 2003

Connection closed by foreign host.

Файл /var/amd/messages (в который, как указано в нашем файле /etc/syslog.conf, должны направляться наши сообщения с аргументом facility=LOG_USER) содержит запись:

Jun 10 11:04:02 solaris daytimetcpsrv3[28724]: connection from 192.168.1.10.58145

Существует три способа установки тайм-аута для операции ввода-вывода через сокет.

1. Вызов функции alarm, которая генерирует сигнал SIGALRM, когда истекает заданное время. Это подразумевает обработку сигналов, которая может варьироваться от одной реализации к другой. К тому же такой подход может стать помехой другим существующим вызовам функции alarm в данном процессе.

2. Блокирование при ожидании ввода-вывода в функции select, имеющей встроенное ограничение времени, вместо блокирования в вызове функции read или write.

3. Использование более новых параметров сокета — SO_RCVTIMEO и SO_SNDTIMEO. Проблема при использовании этого подхода заключается в том, что не все реализации поддерживают новые параметры сокетов.

Все три технологии работают с функциями ввода и вывода (такими как read, write и их вариациями, например recvfrom и sendto), но нам также хотелось бы иметь технологию, работающую с функцией connect, поскольку процесс соединения TCP может занять длительное время (обычно 75 с). Функцию select можно использовать для установки тайм-аута функции connect, только когда сокет находится в неблокируемом режиме (который мы рассматриваем в разделе 16.3), а параметры сокетов, устанавливающие тайм-аут, не работают с функцией connect. Мы также должны отметить, что первые две технологии работают с любым дескриптором, в то время как третья технология только с дескрипторами сокетов.

Теперь мы представим примеры применения всех трех технологий.

Тайм-аут для функции connect (сигнал SIGALRM)

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

Листинг 14.1. Функция connect с тайм-аутом

//lib/connect_timeo.c

 1 #include "unp.h"

 2 static void connect_alarm(int);

 3 int

 4 connect_timeo(int sockfd, const SA *saptr, socklen_t salen, int nsec)

 5 {

 6  Sigfunc *sigfunc;

 7  int n;

 8  sigfunc = Signal(SIGALRM, connect_alarm);

 9  if (alarm(nsec) != 0)

10   err_msg("connect_timeo: alarm was already set");

11  if ((n = connect(sockfd, saptr, salen)) < 0) {

12   close(sockfd);

13   if (errno == EINTR)

14    errno = ETIMEDOUT;

15  }

16  alarm(0); /* отключение alarm */

17  Signal(SIGALRM, sigfunc); /* восстанавливаем прежний обработчик

                                 сигнала */

18  return (n);

19 }

20 static void

21 connect_alarm(int signo)

22 {

23  return; /* просто прерываем connect() */

24 }

Установка обработчика сигналов

8 Для SIGALRM устанавливается обработчик сигнала. Текущий обработчик сигнала (если таковой имеется) сохраняется, и таким образом мы можем восстановить его в конце функции.

Установка таймера

9-10 Таймер для процесса устанавливается на время (число секунд), заданное вызывающим процессом. Возвращаемое значение функции alarm — это число секунд, остающихся в таймере для процесса (если он уже установлен для процесса) в настоящий момент или 0 (если таймер не был установлен прежде). В первом случае мы выводим сообщение с предупреждением, поскольку мы стираем предыдущую установку таймера (см. упражнение 14.2).

Вызов функции connect

11-15 Вызывается функция connect, и если функция прерывается (EINTR), мы присваиваем переменной errno значение ETIMEDOUT. Сокет закрывается, чтобы не допустить продолжения трехэтапного рукопожатия.

Выключение таймера и восстановление предыдущего обработчика сигнала

16-18 Таймер при обнулении выключается, и восстанавливается предыдущий обработчик сигналов (если таковой имеется).

Обработка сигнала SIGALRM

20-24 Обработчик сигнала просто возвращает управление. Предполагается, что это прервет ожидание функции connect, заставив ее возвратить ошибку EINTR. Вспомните нашу функцию signal (см. листинг 5.5), которая не устанавливает флага SA_RESTART, когда перехватываемый сигнал — это сигнал SIGALRM.

Одним из важных моментов в этом примере является то, что мы всегда можем сократить период ожидания для функции connect, используя эту технологию, но мы не можем увеличить период, заданный для ядра. В Беркли-ядре тайм-аут для функции connect обычно равен 75 с. Мы можем задать меньшее значение для нашей функции, допустим 10, но если мы задаем большее значение, скажем 80, тайм- аут самой функции connect все равно составит 75 с.

Другой важный момент в данном примере — то, что мы используем возможность прерывания системного вызова (connect) для того, чтобы возвратить управление, прежде чем истечет время ожидания ядра. Такой подход допустим, когда мы выполняем системный вызов и можем обработать возвращение ошибки EINTR. Но в разделе 29.7 мы встретимся с библиотечной функцией, выполняющей системный вызов, которая сама выполняет заново системный вызов при возвращении ошибки EINTR. Мы можем продолжать работать с сигналом SIGALRM и в этом случае, но в листинге 29.6 мы увидим, что нам придется воспользоваться функциями sigsetjmp и siglongjmp, поскольку библиотечная функция игнорирует ошибку EINTR.

Тайм-аут для функции recvfrom (сигнал SIGALRM)

В листинге 14.2 показана новая версия функции dg_cli, приведенной в листинге 8.4, в которую добавлен вызов функции alarm для прерывания функции recvfrom при отсутствии ответа в течение 5 с.

Листинг 14.2. Функция dg_cli, в которой при установке тайм-аута для функции recvfrom используется функция alarm

//advio/dgclitimeo3.c

 1 #include "unp.h"

 2 static void signalrm(int);

 3 void

 4 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)

 5 {

 6  int n;

 7  char sendline[MAXLINE], recvline[MAXLINE + 1];

 8  Signal(SIGALRM, signalrm);

 9  while (Fgets(sendline, MAXLINE, fp) != NULL) {

10   Sendto(sockfd, sendline, strlen(sendline), 0, pservaddr, servlen);

11   alarm(5);

12   if ((n = recvfrom(sockfd, recvline, MAXLINE, 0, NULL, NULL)) < 0) {

13    if (errno == EINTR)

14     fprintf(stderr, "socket timeout\n");

15    else

16     err_sys("recvfrom error");

17   } else {

18    alarm(0);

19    recvline[n] = 0; /* завершающий нуль */

20    Fputs(recvline, stdout);

21   }

22  }

23 }

24 static void

25 sig_alrm(int signo)

26 {

27  return; /* просто прерываем recvfrom() */

28 }

Обработка тайм-аута из функции recvfrom

8-22 Мы устанавливаем обработчик для сигнала SIGALRM и затем вызываем функцию alarm для 5-секундного тайм-аута при каждом вызове функции recvfrom. Если функция recvfrom прерывается нашим обработчиком сигнала, мы выводим сообщение об ошибке и продолжаем работу. Если получена строка от сервера, мы отключаем функцию alarm и выводим ответ.

Обработчик сигнала SIGALRM

24-28 Наш обработчик сигналов возвращает управление, прерывая блокированную функцию recvfrom.

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

Тайм-аут для функции recvfrom (функция select)

Мы демонстрируем вторую технологию для установки тайм-аута (использование функции select) в листинге 14.3. Здесь показана наша функция readable_timeo, которая ждет, когда дескриптор станет готов для чтения, но не более заданного числа секунд.

Листинг 14.3. Функция readable_timeo: ожидание, когда дескриптор станет готов для чтения

//lib/readable_timео.c

 1 #include "unp.h"

 2 int

 3 readable_timeo(int fd, int sec)

 4 {

 5  fd_set rset;

 6  struct timeval tv;

 7  FD_ZERO(&rset);

 8  FD_SET(fd, &rset);

 9  tv.tv_sec = sec;

10  tv.tv_usec = 0;

11  return (select(fd + 1, &rset, NULL, NULL, &tv));

12  /* > если дескриптор готов для чтения */

13 }

Подготовка аргументов для функции select

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

Блокирование в функции select

11-12 Функция select ждет, когда дескриптор станет готов для чтения или истечет заданное время ожидания. Возвращаемое значение этой функции — это возвращаемое значение функции select: -1 в случае ошибки, 0, если истекло время ожидания, и положительное значение, задающее число готовых дескрипторов, если таковые появились.

Эта функция не выполняет операции чтения — она просто ждет, когда дескриптор будет готов к чтению. Следовательно, эту функцию можно использовать с любым типом сокета — TCP или UDP.

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

Мы используем эту функцию в листинге 14.4, где показана еще одна версия нашей функции dg_cli, приведенной в листинге 8.4. Эта новая версия вызывает функцию recvfrom, только когда наша функция readable_timeo возвращает положительное значение.

Мы не вызываем функцию recvfrom, пока функция readable_timeo не сообщит нам, что дескриптор готов для чтения. Тем самым мы гарантируем, что функция recvfrom не заблокируется.

Листинг 14.4. Функция dg_cli, вызывающая функцию readable_timeo для установки тайм-аута

//advio/dgclitimeo1.c

 1 #include "unp.h"

 2 void

 3 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)

 4 {

 5  int n;

 6  char sendline[MAXLINE], recvline[MAXLINE + 1];

 7  while (Fgets(sendline, MAXLINE, fp) != NULL) {

 8   Sendto(sockfd, sendline, strlen(sendline), 0, pservaddr, servlen);

 9   if (Readable_timeo(sockfd, 5) == 0) {

10    fprintf(stderr, "socket timeout\n");

11   } else {

12    n = Recvfrom(sockfd, recvline, MAXLINE, 0, NULL, NULL);

13    recvline[n] = 0; /* завершающий нуль */

14    Fputs(recvline, stdout);

15   }

16  }

17 }

Тайм-аут для функции recvfrom (параметр сокета SO_RCVTIMEO)

В нашем последнем примере демонстрируется применение параметра сокета SO_RCVTIMEO. Мы устанавливаем этот параметр один раз для дескриптора, задавая значение тайм-аута, и этот тайм-аут затем применяется ко всем операциям чтения этого дескриптора. Одна из замечательных особенностей этого метода состоит в том, что мы устанавливаем данный параметр только один раз, тогда как предыдущие два метода требовали выполнения некоторых действий перед каждой операцией, для которой мы хотели задать временной предел. Но этот параметр сокета применяется только к операциям чтения. Аналогичный параметр SO_SNDTIMEO применяется только к операциям записи, и ни один параметр сокета не может использоваться для установки тайм-аута для функции connect.

Листинг 14.5. Функция dg_cli, использующая параметр сокета SO_RCVTIMEO для установки тайм-аута

//advio/dgclitimeo2.c

 1 #include "unp.h"

 2 void

 3 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)

 4 {

 5  int n;

 6  char sendline[MAXLINE], recvline[MAXLINE + 1];

 7  struct timeval tv;

 8  tv.tv_sec = 5;

 9  tv.tv_usec = 0;

10  Setsockopt(sockfd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));

11  while (Fgets(sendline, MAXLINE, fp) != NULL) {

12    Sendto(sockfd, sendline, strlen(sendline), 0, pservaddr, servlen);

13    n = recvfrom(sockfd, recvline, MAXLINE, 0, NULL, NULL);

14    if (n < 0) {

15     if (errno == EWOULDBLOCK) {

16     fprintf(stderr, "socket timeout\n");

17     continue;

18    } else

19     err_sys("recvfrom error");

20   }

21   recvline[n] = 0; /* завершающий нуль */

22   Fputs(recvline, stdout);

23  }

24 }

Установка параметра сокета

8-10 Четвертый аргумент функции setsockopt — это указатель на структуру timeval, в которую записывается желательное значение тайм-аута.

Проверка тайм-аута

15-17 Если тайм-аут операции ввода-вывода истекает, функция (в данном случае recvfrom) возвращает ошибку EWOULDBLOCK.

Во всех наших примерах мы применяли то, что иногда называется вводом-выводом Unix, вызывали функции read и write и их разновидности (recv, send и т.д.). Эти функции работают с дескрипторами и обычно реализуются как системные вызовы внутри ядра Unix.

Другой метод выполнения ввода-вывода заключается в использовании стандартной библиотеки ввода-вывода. Она задается стандартом ANSI С и была задумана как библиотека, совместимая с не-Unix системами, поддерживающими ANSI С. Стандартная библиотека ввода-вывода обрабатывает некоторые моменты, о которых мы должны заботиться сами при использовании функций ввода- вывода Unix, таких как автоматическая буферизация потоков ввода и вывода. К сожалению, ее обработка буферизации потока может представить новый ряд проблем, о которых следует помнить. Глава 5 [110] подробно описывает стандартную библиотеку ввода-вывода, а в [92] представлена полная реализация стандартной библиотеки ввода-вывода и ее обсуждение.

ПРИМЕЧАНИЕ

При обсуждении стандартной библиотеки ввода-вывода используется термин «поток» в выражениях типа «мы открываем поток ввода» или «мы очищаем поток вывода». Не путайте это с подсистемой потоков STREAMS, которую мы обсуждаем в главе 31.

Стандартная библиотека ввода-вывода может использоваться с сокетами, но есть несколько моментов, которые необходимо при этом учитывать.

■ Стандартный поток ввода-вывода может быть создан из любого дескриптора при помощи вызова функции fdopen. Аналогично, имея стандартный поток ввода-вывода, мы можем получить соответствующий дескриптор, вызывая функцию fileno. С функцией fileno мы впервые встретились в листинге 6.1, когда мы хотели вызвать функцию select для стандартного потока ввода-вывода. Функция select работает только с дескрипторами, поэтому нам необходимо было получить дескриптор для стандартного потока ввода-вывода.

■ Сокеты TCP и UDP являются двусторонними. Стандартные потоки ввода- вывода также могут быть двусторонними: мы просто открываем поток типа r+, что означает чтение-запись. Но в таком потоке за функцией вывода не может следовать функция ввода, если между ними нет вызова функции fflush, fseek, fsetpots или rewind. Аналогично, за функцией вывода не может следовать функция ввода, если между ними нет вызова функции fseek, fsetpots, rewind, в том случае, когда при вводе не получен признак конца файла. Проблема с последними тремя функциями состоит в том, что все они вызывают функцию lseek, которая не работает с сокетами.

■ Простейший способ обработки подобной проблемы чтения-записи — это открытие двух стандартных потоков ввода-вывода для данного сокета: одного для чтения и другого для записи.

Пример: функция str_echo, использующая стандартный ввод-вывод

Сейчас мы модифицируем наш эхо-сервер TCP (см. листинг 5.2) для использования стандартного ввода-вывода вместо функций readline и writen. В листинге 14.6 представлена версия нашей функции str_echo, использующая стандартный ввод-вывод. (С этой версией связана проблема, которую мы вскоре опишем.)

Листинг 14.6. Функция str_echo, переписанная с использованием стандартного ввода-вывода

//advio/str_echo_stdiо02.с

 1 #include "unp.h"

 2 void

 3 str_echo(int sockfd)

 4 {

 5  char line[MAXLINE];

 6  FILE *fpin, *fpout;

 7  fpin = Fdopen(sockfd, "r");

 8  fpout = Fdopen(sockfd, "w");

 9  while (Fgets(line, MAXLINE, fpin) != NULL)

10  Fputs(line, fpout);

11 }

Преобразование дескриптора в поток ввода и поток вывода

7-10 Функцией fdopen создаются два стандартных потока ввода-вывода: один для ввода и другой для вывода. Вызовы функций readline и writen заменены вызовами функций fgets и fputs.

Если мы запустим наш сервер с этой версией функции str_echo и затем запустим наш клиент, мы увидим следующее:

hpux % tcpcli02 206.168.112.96

hello, world мы набираем эту строку, но не получаем отражения

and hi        и на эту строку нет ответа

hello??       и на эту строку нет ответа

^D            наш символ конца файла

hello, world затем выводятся три отраженные строки

and hi

hello??

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

■ Мы набираем первую строку ввода, и она отправляется серверу.

■ Сервер читает строку с помощью функции fgets и отражает ее с помощью функции fputs.

■ Но стандартный поток ввода-вывода сервера полностью буферизован стандартной библиотекой ввода-вывода. Это значит, что библиотека копирует отраженную строку в свой стандартный буфер ввода-вывода для этого потока, но не выдает содержимое буфера в дескриптор, поскольку буфер не заполнен.

■ Мы набираем вторую строку ввода, и она отправляется серверу.

■ Сервер читает строку с помощью функции fgets и отражает ее с помощью функции fputs.

■ Снова стандартная библиотека ввода-вывода сервера только копирует строку в свой буфер, но не выдает содержимое буфера в дескриптор, поскольку он не заполнен.

■ По тому же сценарию вводится третья строка.

■ Мы набираем наш символ конца файла, и функция str_cli (см. листинг 6.2) вызывает функцию shutdown, посылая серверу сегмент FIN.

■ TCP сервера получает сегмент FIN, который читает функция fgets, в результате чего функция fgets возвращает пустой указатель.

■ Функция str_echo возвращает серверу функцию main (см. листинг 5.9), и дочерний процесс завершается при вызове функции exit.

■ Библиотечная функция exit языка С вызывает стандартную функцию очистки ввода-вывода [110, с. 162-164], и буфер вывода, который был частично заполнен нашими вызовами функции fputs, теперь выводит скопившиеся в нем данные.

■ Дочерний процесс сервера завершается, в результате чего закрывается его присоединенный сокет, клиенту отсылается сегмент FIN и заканчивается последовательность завершения соединения TCP.

■ Наша функция str_cli получает и выводит три отраженных строки.

■ Затем функция str_cli получает символ конца файла на своем сокете, и клиент завершает свою работу.

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

1. Полная буферизация (fully buffered) означает, что ввод-вывод имеет место, только когда буфер заполнен, процесс явно вызывает функцию fflush или процесс завершается посредством вызова функции exit. Обычный размер стандартного буфера ввода-вывода — 8192 байта.

2. Буферизация по строкам (line buffered) означает, что ввод-вывод имеет место, только когда встречается символ перевода строки, процесс вызывает функцию fflush или процесс завершается вызовом функции exit.

3. Отсутствие буферизации (unbuffered) означает, что ввод-вывод имеет место каждый раз, когда вызывается функция стандартного ввода-вывода.

Большинство реализаций Unix стандартной библиотеки ввода-вывода используют следующие правила:

■ Стандартный поток ошибок никогда не буферизуется.

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

■ Все остальные потоки тоже буферизованы полностью, если они не подключены к терминалу, в случае чего они буферизованы по строкам.

Поскольку сокет не является терминальным устройством, проблема, отмеченная с нашей функцией str_echo в листинге 14.6, заключается в том, что поток вывода (fpot) полностью буферизован. Есть два решения: мы можем сделать поток вывода буферизованным по строкам при помощи вызова функции setvbuf либо заставить каждую отраженную строку выводиться при помощи вызова функции fflush после каждого вызова функции fputs. Применение любого из этих изменений скорректирует поведение нашей функции str_echo. На практике оба варианта чреваты ошибками и могут плохо взаимодействовать с алгоритмом Нагла. В большинстве случаев оптимальным решением будет отказаться от использования стандартной библиотеки ввода-вывода для сокетов и работать с буферами, а не со строками (см. раздел 3.9). Использование стандартных функций ввода-вывода имеет смысл в тех случаях, когда потенциальный выигрыш перевешивает затруднения.

ПРИМЕЧАНИЕ

Будьте осторожны — некоторые реализации стандартной библиотеки ввода-вывода все еще вызывают проблемы при работе с дескрипторами, большими 255. Эта проблема может возникнуть с сетевыми серверами, обрабатывающими множество дескрипторов. Проверьте определение структуры FILE в вашем заголовочном файле <stdio.h>, чтобы увидеть, к какому типу переменных относится дескриптор.

В начале этой главы мы рассказывали о способах установки таймеров для операций с сокетами. Во многих операционных системах для этого существуют функции poll и select, которые были описаны в главе 6. Ни один из этих методов еще не стандартизован POSIX, поэтому между реализациями существуют определенные различия. Код, использующий подобные механизмы, должен считаться непереносимым. Мы рассмотрим два механизма, прочие весьма похожи на них.

Интерфейс /dev/poll

В Solaris имеется специальный файл /dev/poll, с помощью которого можно опрашивать большее количество дескрипторов файлов. Проблема select и poll состоит в том, что список дескрипторов приходится передавать при каждом вызове. Устройство опроса поддерживает информацию о состоянии между вызовами, так что программа может подготовить список подлежащих опросу дескрипторов, а потом спокойно зациклиться в опросе и не заполнять список каждый раз.

После открытия /dev/poll программа должна инициализировать массив структур pollfd (тех же, которые используются функцией poll, но в этом случае поле revents не используется). Затем массив передается ядру вызовом write (структура записывается непосредственно в /dev/poll). После этого программа может вызывать ioctl DP_POLL и ждать событий. При вызове ioctl передается следующая структура:

struct dvpoll {

 struct pollfd* dp_fds;

 int            dp_nfds;

 int            dp_timeout;

};

Поле dp_fds указывает на буфер, используемый для хранения массива структур pollfd, возвращаемых вызовом ioctl. Поле dp_nfds задает размер буфера. Вызов ioctl блокируется до появления интересующих программу событий на любом из опрашиваемых дескрипторов, или до прохождения dp_timeout миллисекунд. При нулевом значении тайм-аута функция ioctl возвращается немедленно (то есть данный способ может использоваться для реализации неблокируемых сокетов). Тайм-аут, равный -1, означает неопределенно долгое ожидание.

Измененный код функции str_cli, переписанной из листинга 6.2 с использованием /dev/poll, приведен в листинге 14.7.

Листинг 14.7. Функция str_cli, использующая /dev/poll

//advio/str_cli_poll03.c

 1 #include "unp.h"

 2 #include

 3 void

 4 str_cli(FILE *fp, int sockfd)

 5 {

 6  int stdineof;

 7  char buf[MAXLINE];

 8  int n;

 9  int wfd;

10  struct pollfd pollfd[2];

11  struct dvpoll dopoll;

12  int i;

13  int result;

14  wfd = Open("/dev/poll", O_RDWR, 0);

15  pollfd[0].fd = fileno(fp);

16  pollfd[0].events = POLLIN;

17  pollfd[0].revents = 0;

18  pollfd[1].fd = sockfd;

19  pollfd[1].events = POLLIN;

20  pollfd[1].revents = 0;

21  Write(wfd, pollfd, sizeof(struct pollfd) * 2);

22  stdineof = 0;

23  for (;;) {

24   /* блокирование до готовности сокета */

25   dopoll.dp_timeout = -1;

26   dopoll.dp_nfds = 2;

27   dopoll.dp_fds = pollfd;

28   result = Ioctl(wfd, DP_POLL, &dopoll);

29   /* цикл по готовым дескрипторам */

30   for (i = 0; i < result; i++) {

31    if (dopoll.dp_fds[i].fd == sockfd) {

32     /* сокет готов к чтению */

33     if ((n = Read(sockfd, buf, MAXLINE)) == 0) {

34      if (stdineof == 1)

35       return; /* нормальное завершение */

36      else

37       err_quit("str_cli: server terminated prematurely");

38     }

39     Write(fileno(stdout), buf, n);

40    } else {

41     /* дескриптор готов к чтению */

42     if ((n = Read(fileno(fp), buf, MAXLINE)) == 0) {

43      stdineof = 1;

44      Shutdown(sockfd, SHUT_WR); /* отправка FIN */

45      continue;

46     }

47     Writen(sockfd, buf, n);

48    }

49   }

50  }

51 }

Составление списка дескрипторов для /dev/poll

14-21 Заполнив массив структур pollfd, мы передаем его в /dev/poll. В нашем примере используются только два файловых дескриптора, так что мы помещаем их в статический массив. На практике программы, использующие /dev/poll, обычно следят за сотнями или даже тысячами дескрипторов одновременно, поэтому массив выделяется динамически.

Ожидание данных

24-28 Программа не вызывает select, а блокируется в вызове ioctl в ожидании поступления данных. Возвращаемое значение представляет собой количество готовых к чтению дескрипторов файлов.

Цикл по дескрипторам

30-49 Наша программа относительно проста, потому что мы знаем, что дескрипторов всего два. В большой программе цикл будет более сложным. Возможно даже разделение программы на потоки для обработки данных, полученных по разным дескрипторам.

Интерфейс kqueue

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

#include

#include

#include

int kqueue(void);

int kevent(int kq , const struct kevent * changelist , int nchanges ,

 struct kevent * eventlist , int nevents , const struct timespec * timeout );

void EV_SET(struct kevent * kev , uintptr_t ident , short filter ,

 u_short flags , u_int fflags , intptr_t data , void * udata );

Функция kqueue возвращает новый дескриптор kqueue, который может использоваться в последующих вызовах kevent. Функция kevent применяется для регистрации интересующих событий, а также для получения уведомлений об этих событиях. Параметры changelist и nchanges описывают изменения в предыдущем варианте списка событий. Если nchanges отлично от нуля, выполняются все запрошенные в структуре changelist изменения. Функция kevent возвращает количество событий или нуль, если произошел выход по тайм-ауту. В аргументе timeout хранится значение тайм-аута, обрабатываемое подобно тому, как при вызове select (NULL для блокирования, ненулевое значение для задания конкретного тайм- аута, а нулевое значение трактуется как необходимость неблокирующего вызова). Обратите внимание, что параметр timeout имеет тип struct timespec, отличающийся от struct timeval в вызове select тем, что первый имеет наносекундное разрешение, а второй — микросекундное.

Структура kevent определяется в заголовочном файле :

struct kevent {

 uintptr_t ident;  /* идентификатор (например, дескриптор файла) */

 short     filter; /* тип фильтра (например, EVFILT_READ) */

 u_short   flags;  /* флаги действий (например, EV_ADD); */

 u_int     fflags; /* флаги, относящиеся к конкретным фильтрам */

 intptr_t  data;   /* данные, относящиеся к конкретным фильтрам */

 void      uidata; /* непрозрачные пользовательские данные */

};

Действия по смене фильтра и флаговые возвращаемые значения приведены в табл. 14.5.

Таблица 14.5. Флаги для операций kevent

Типы фильтров приведены в табл. 14.6.

Таблица 14.6. Типы фильтров

Перепишем функцию str_cli из листинга 6.2 так, чтобы она использовала kqueue. Результат представлен в листинге 14.8.

Листинг 14.8. Функция str_cli, использующая kqueue

//advio/str_cli_kqueue04.c

 1 #include "unp.h"

 2 void

 3 str_cli(FILE *fp, int sockfd)

 4 {

 5  int kq, i, n, nev, stdineof = 0, isfile;

 6  char buf[MAXLINE];

 7  struct kevent kev[2];

 8  struct timespec ts;

 9  struct stat st;

10  isfile = ((fstat(fileno(fp), &st) 0) &&

11   (st.st_mode & S_IFMT) == S_IFREG);

12  EV_SET(&kev[0], fileno(fp), EVFILT_READ, EV_ADD, 0, 0, NULL);

13  EV_SET(&kev[1], sockfd, EVFILT_READ, EV_ADD, 0, 0, NULL);

14  kq = Kqueue();

15  ts.tv_sec = ts.tv_nsec = 0;

16  Kevent(kq, kev, 2, NULL, 0, &ts);

17  for (;;) {

18   nev = Kevent(kq, NULL, 0, kev, 2, NULL);

19   for (i = 0; i < nev; i++) {

20    if (kev[i].ident == sockfd) { /* сокет готов для чтения */

21     if ((n = Read(sockfd, buf, MAXLINE)) == 0) {

22      if (stdineof == 1)

23       return; /* нормальное завершение*/

24      else

25       err_quit("str_cli: server terminated prematurely");

26     }

27     Write(fileno(stdout), buf, n);

28    }

29    if (kev[i].ident == fileno(fp)) { /* входной поток готов к чтению */

30     n = Read(fileno(fp), buf, MAXLINE);

31     if (n > 0)

32      Writen(sockfd, buf, n);

33     if (n == 0 || (isfile && n == kev[i].data)) {

34      stdineof = 1;

35      Shutdown(sockfd, SHUT_WR); /* отправка FIN */

36      kev[i].flags = EV_DELETE;

37      Kevent(kq, &kev[i], 1, NULL, 0, &ts); /* удаление

                                                 kevent */

38      continue;

39     }

40    }

41   }

42  }

43 }

Проверка, указывает ли дескриптор на файл

10-11 Поведение kqueue при достижении конца файла зависит от того, связан ли данный дескриптор с файлом, каналом или терминалом, поэтому мы вызываем fstat, чтобы убедиться, что мы работаем с файлом. Эти сведения понадобятся позже.

Настройка структур kevent для kqueue

12-13 При помощи макроса EV_SET мы настраиваем две структуры kevent. Обе содержат фильтр событий готовности к чтению (EVFILT_READ) и запрос на добавление этого события к фильтру (EV_ADD).

Создание kqueue и добавление фильтров

14-16 Мы вызываем kqueue, чтобы получить дескриптор kqueue, устанавливаем тайм- аут равным нулю, чтобы сделать вызов kevent неблокируемым, и наконец, вызываем kevent с массивом kevent на месте соответствующего аргумента.

Бесконечный цикл с блокированием в kevent

17-18 Мы входим в бесконечный цикл и блокируемся в kevent. Функции передается пустой список изменений, потому что все интересующие нас события уже зарегистрированы, и нулевой тайм-аут, что позволяет заблокироваться навечно.

Перебор возвращаемых событий в цикле

19 Мы проверяем все возвращаемые события и обрабатываем их последовательно.

Сокет готов для чтения

20-28 Эта часть кода ничем не отличается от листинга 6.2.

Вход готов для чтения

29-40 Код практически аналогичен листингу 6.2 за тем отличием, что нам приходится обрабатывать конец файла, возвращаемый kqueue. Для каналов и терминалов kqueue возвращает событие готовности дескриптора к чтению, подобно select, так что мы можем считать из этого дескриптора символ конца файла. Для файлов kqueue возвращает количество байтов, оставшихся в поле data структуры struct kevent и предполагает, что приложение само определит, когда оно доберется до конца этих данных. Поэтому мы переписываем цикл таким образом, чтобы отправлять данные по сети, если они были считаны из дескриптора. Затем проверяется достижение конца файла: если мы считали нуль байтов или если мы считали все оставшиеся байты из дескриптора файла, значит, это и есть EOF. Еще одно изменение состоит в том, что вместо FD_CLR для удаления дескриптора из набора файлов мы используем флаг EV_DELETE и вызываем kevent для удаления события из фильтра в ядре.

Рекомендации

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

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

В листинге 15.1 показана структура адреса доменного сокета Unix, задаваемая включением заголовочного файла .

Листинг 15.1. Структура адреса доменного сокета Unix: sockaddr_un

struct sockaddr_un {

 uint8_t     sun_len;

 sa_family_t sun_family;    /* AF_LOCAL */

 char        sun_path[104]; /* полное имя, оканчивающееся нулем */

};

ПРИМЕЧАНИЕ

POSIX не задает длину массива sun_path и предупреждает, что разработчику приложения не следует делать предположений об этой длине. Воспользуйтесь оператором sizeof для определения длины массива во время выполнения программы. Убедитесь, что полное имя помещается в этот массив. Длина, скорее всего, будет где-то между 92 и 108. Причина этих ограничений — в артефакте реализации, возникшем еще в 4.2BSD, где требовалось, чтобы структура помещалась в 128-байтовый буфер памяти ядра mbuf.

Полное имя, хранимое в символьном массиве sun_path, должно завершаться нулем. Имеется макрос SUN_LEN, который получает указатель на структуру sockaddr_un и возвращает длину структуры, включая число непустых байтов в полном имени. Неопределенный адрес обозначается пустой строкой, то есть элемент sun_path[0] должен быть равен нулю. Это эквивалент константы INADDR_ANY протокола IPv4 и константы IN6ADDR_ANY_INIT протокола IPv6 для домена Unix.

ПРИМЕЧАНИЕ

В POSIX доменным протоколам Unix дали название «локального IPC», чтобы не подчеркивать зависимость от операционной системы Unix. Историческая константа AF_UNIX становится константой AF_LOCAL. Тем не менее мы будем продолжать использовать термин «домен Unix», так как он стал именем де-факто, независимо от соответствующей операционной системы. Кроме того, несмотря на попытку POSIX исключить зависимость от операционной системы, структура адреса сокета сохраняет суффикс _un!

Пример: функция bind и доменный сокет Unix

Программа, показанная в листинге 15.2, создает доменный сокет Unix, с помощью функции bind связывает с ним полное имя и затем вызывает функцию getsockname и выводит это полное имя.

Листинг 15.2. Связывание полного имени с доменным сокетом Unix

unixdomain/unixbind.c

 1 #include "unp.h"

 2 int

 3 main(int argc, char **argv)

 4 {

 5  int sockfd;

 6  socklen_t len;

 7  struct sockaddr_un addr1, addr2;

 8  if (argc != 2)

 9   err_quit("usage: unixbind ");

10  sockfd = Socket(AF_LOCAL, SOCK_STREAM, 0);

11  unlink(argv[1]); /* игнорируем возможную ошибку */

12  bzero(&addr1, sizeof(addr1));

13  addr1.sun_family = AF_LOCAL;

14  strncpy(addr1.sun_path, argv[1], sizeof(addr1.sun_path) - 1);

15  Bind(sockfd, (SA*)&addr1, SUN_LEN(&addr1));

16  len = sizeof(addr2);

17  Getsockname(sockfd, (SA*)&addr2, &len);

18  printf("bound name = %s, returned len = %d\n", addr2.sun_path, len);

19  exit(0);

20 }

Удаление файла

11 Полное имя, которое функция bind должна связать с сокетом, — это аргумент командной строки. Если это полное имя уже существует в файловой системе, при выполнении функции bind возникает ошибка. Следовательно, мы вызываем функцию unlink, чтобы удалить файл в том случае, если он уже существует. Если его не существует, функция unlink возвращает ошибку, которую мы игнорируем.

Вызов функций bind и getsockname

12-18 Мы копируем аргумент командной строки, используя функцию strncpy, чтобы избежать переполнения структуры, если полное имя слишком длинное. Поскольку мы инициализируем структуру нулем и затем вычитаем единицу из размера массива sun_path, мы знаем, что полное имя оканчивается нулем. Далее вызывается функция bind и мы используем макрос SUN_LEN для вычисления длины аргумента функции. Затем мы вызываем функцию getsockname, чтобы получить имя, которое было только что связано с сокетом, и выводим результат.

Если мы запустим программу в Solaris, то получим следующие результаты:

solaris % umask   сначала выводим наше значение umask

022             оно отображается в восьмеричной системе

solaris % unixbind /tmp/moose

bound name = /tmp/moose, returned len = 13

solaris % unixbind /tmp/moose   снова запускаем программу

bound name = /tmp/moose, returned len = 13

solaris % ls -l /tmp/moose

srwxr-xr-x 1 andy staff 0 Aug 10 13:13 /tmp/moose

solaris % ls -lF /tmp/foo.bar

srwxr-xr-x 1 andy staff 0 Aug 10 13:13 /tmp/moose=

Сначала мы выводим наше значение umask, поскольку в POSIX указано, что права доступа к создаваемому объекту определяются этим значением. Наше значение 022 выключает биты, разрешающие запись в файл для пользователей из группы (group-write) и прочих пользователей (other-write). Затем мы запускаем программу и видим, что длина, возвращаемая функцией getsockname, равна 13: один байт для элемента sun_len, один байт для элемента sun_family и 11 байт для полного имени (исключая завершающий нуль). Это пример аргумента типа «значение-результат», значение которого при завершении функции отличается от значения при вызове функции. Мы можем вывести полное имя, используя спецификатор формата %s функции printf, поскольку полное имя, хранящееся в sun_path, представляет собой завершающуюся нулем строку. Затем мы снова запускаем программу, чтобы проверить, что вызов функции unlink удаляет соответствующий файл.

Мы запускаем команду ls -l, чтобы увидеть биты разрешения для файла и тип файла. В Solaris (и большинстве версий Unix) тип файла — это сокет, что обозначается символом s. Мы также замечаем, что все девять битов разрешения включены, так как Solaris не изменяет принятые по умолчанию биты разрешения на наше значение umask. Наконец, мы снова запускаем ls с параметром -F, что заставляет Solaris добавить знак равенства (соответствующий типу «сокет») к полному имени.

ПРИМЕЧАНИЕ

Изначально значение umask не действовало на создаваемые процессами доменные сокеты Unix, но с течением времени производители исправили это упущение, чтобы устанавливаемые разрешения соответствовали ожиданиям разработчиков. Тем не менее все еще существуют системы, в которых разрешения доменного сокета могут не зависеть от значения umask. В других системах сокеты могут отображаться как каналы (символ р), а значок равенства при вызове ls -F может не отображаться вовсе. Однако поведение, демонстрируемое в нашем примере, является наиболее типичным.

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

1. Дочерний процесс использует все открытые дескрипторы совместно с родительским процессом после вызова функции fork.

2. Все дескрипторы обычно остаются открытыми при вызове функции exec.

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

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

ПРИМЕЧАНИЕ

Передача ядром 4.4BSD открытого дескриптора через доменный сокет Unix описывается в главе 18 [112].

SVR4 использует другую технологию внутри ядра для передачи открытого дескриптора: команды I_SENDFD и I_RECVFD функции ioctl, описанные в разделе 15.5.1 [110]. Но процесс все же имеет возможность доступа к указанному свойству ядра за счет доменного сокета Unix. В этой книге мы описываем применение доменных сокетов Unix для передачи открытых дескрипторов, поскольку это наиболее переносимая технология программирования: она работает как с Беркли-ядрами, так и с SVR4, в то время как команды I_SENDFD и I_RECVFD функции ioctl работают только в SVR4.

Технология 4.4BSD позволяет передавать множество дескрипторов с помощью одиночной функции sendmsg, в то время как технология SVR4 передает за один раз только один дескриптор. Во всех наших примерах за один раз передается один дескриптор.

Шаги при передаче дескриптора между процессами будут такими:

1. Создание доменного сокета Unix, или потокового сокета, или дейтаграммного сокета.

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

Если процессы не являются родственными, сервер должен создать потоковый доменный сокет Unix, связать его при помощи функции bind с полным именем, тем самым позволяя клиенту соединиться с этим сокетом при помощи функции connect. Затем клиент может отправить запрос серверу для открытия некоторого дескриптора, а сервер может передать дескриптор обратно через доменный сокет Unix. Как альтернатива между клиентом и сервером может также использоваться дейтаграммный доменный сокет Unix, однако преимущества этого способа невелики, к тому же существует возможность игнорирования дейтаграммы. Далее в примерах этой главы мы будем использовать потоковый сокет между клиентом и сервером.

2. Один процесс открывает дескриптор при помощи вызова любой из функций Unix, возвращающей дескриптор, например open, piре, mkfifo, socket или accept. От одного процесса к другому можно передать дескриптор любого типа, поэтому мы называем эту технологию «передачей дескриптора», а не «передачей дескриптора файла».

3. Отправляющий процесс строит структуру msghdr (см. раздел 14.5), содержащую дескриптор, который нужно передать. В POSIX определено, что дескриптор должен отправляться как вспомогательные данные (элемент msg_control структуры msghdr, см. раздел 14.6), но более старые реализации используют элемент msg_accrights. Отправляющий процесс вызывает функцию sendmsg для отправки дескриптора через доменный сокет Unix, созданный на шаге 1. На этом этапе мы говорим, что дескриптор находится «в полете». Даже если отправляющий процесс закроет дескриптор после вызова функции sendmsg, но до вызова принимающим процессом функции recvmsg, дескриптор останется открытым для принимающего процесса. Отправка дескриптора увеличивает счетчик ссылок дескриптора на единицу.

4. Принимающий процесс вызывает функцию recvmsg для получения дескриптора через доменный сокет Unix, созданный на шаге 1. Номер дескриптора в принимающем процессе может отличаться от номера дескриптора в отправляющем процессе. Передача дескриптора — это не передача номера дескриптора. Этот процесс включает создание нового дескриптора в принимающем процессе, который ссылается на ту же запись таблицы файлов в ядре, что и дескриптор, отправленный отправляющим процессом.

Клиент и сервер должны располагать некоторым протоколом уровня приложения, с тем чтобы получатель дескриптора имел информацию о времени его появления. Если получатель вызывает функцию recvmsg, не выделив места в памяти для получения дескриптора, и дескриптор передается как готовый для чтения, то передаваемый дескриптор закрывается [128, с. 518]. Кроме того, нужно избегать установки флага MSG_PEEK в функции recvmsg, если предполагается получение дескриптора, поскольку в этом случае результат непредсказуем.

Пример передачи дескриптора

Теперь мы представим пример передачи дескриптора. Мы напишем программу под названием mycat, которой в качестве аргумента командной строки передается полное имя файла. Эта программа открывает файл и копирует его в стандартный поток вывода. Но вместо вызова обычной функции Unix open мы вызываем нашу собственную функцию my_open. Эта функция создает потоковый канал и вызывает функции fork и exec для запуска другой программы, открывающей нужный файл. Эта программа должна затем передать дескриптор обратно родительскому процессу по потоковому каналу.

На рис. 15.1 показан первый шаг: наша программа mycat после создания потокового канала при помощи вызова функции socketpair. Мы обозначили два дескриптора, возвращаемых функцией socketpair, как [0] и [1].

Рис. 15.1. Программа mycat после создания потокового канала при использовании функции socketpair

Затем процесс взывает функцию fork, и дочерний процесс вызывает функцию exec для выполнения программы openfile. Родительский процесс закрывает дескриптор [1], а дочерний процесс закрывает дескриптор [0]. (Нет разницы, на каком конце потокового канала происходит закрытие. Дочерний процесс мог бы закрыть [1], а родительский — [0].) При этом получается схема, показанная на рис. 15.2.

Рис. 15.2. Программа mycat после запуска программы openfile

Родительский процесс должен передать программе openfile три фрагмента информации: полное имя открываемого файла, режим открытия (только чтение чтение и запись или только запись) и номер дескриптора, соответствующий его концу потокового канала (который мы обозначили [1]). Мы выбрали такой способ передачи этих трех элементов, как ввод аргументов командной строки при вызове функции exec. Альтернативным способом будет отправка этих элементов в качестве данных по потоковому каналу. Программа отправляет обратно открытый дескриптор по потоковому каналу и завершается. Статус выхода программы сообщает родительскому процессу, смог ли файл открыться, и если нет, то какого типа ошибка произошла.

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

Листинг 15.7. Программа mycat: копирование файла в стандартный поток вывода

//unixdomain/mycat.c

 1 #include "unp.h"

 2 int my_open(const char*, int);

 3 int

 4 main(int argc, char **argv)

 5 {

 6  int fd, n;

 7  char buff[BUFFSIZE];

 8  if (argc != 2)

 9   err_quit("usage: mycat ");

10  if ((fd = my_open(argv[1], O_RDONLY)) < 0)

11   err_sys("cannot open %s", argv[1]);

12  while ((n = Read(fd, buff, BUFFSIZE)) > 0)

13   Write(STDOUT_FILENO, buff, n);

14  exit(0);

15 }

Если мы заменим вызов функции my_open вызовом функции open, эта простая программа всего лишь скопирует файл в стандартный поток вывода.

Функция my_open, показанная в листинге 15.8, должна выглядеть для вызывающего процесса как обычная функция Unix open. Она получает два аргумента — полное имя и режим открытия (например, O_RDONLY обозначает, что файл доступен только для чтения), открывает файл и возвращает дескриптор.

Листинг 15.8. Функция my_open: открытие файла и возвращение дескриптора

//unixdomain/myopen.c

 1 #include "unp.h"

 2 int

 3 my_open(const char *pathname, int mode)

 4 {

 5  int fd, sockfd[2], status;

 6  pid_t childpid;

 7  char c, argsockfd[10], argmode[10];

 8  Socketpair(AF_LOCAL, SOCK_STREAM, 0, sockfd);

 9  if ((childpid = Fork()) == 0) { /* дочерний процесс */

10   Close(sockfd[0]);

11   snprintf(argsockfd, sizeof(argsockfd), "%d", sockfd[1]);

12   snprintf(argmode, sizeof(argmode), "%d", mode);

13   execl("./openfile", "openfile", argsockfd, pathname, argmode,

14    (char*)NULL);

15   err_sys("execl error");

16  }

17  /* родительский процесс - ожидание завершения дочернего процесса */

18  Close(sockfd[1]); /* закрываем конец, который мы не используем */

19  Waitpid(childpid, &status, 0);

20  if (WIFEXITED(status) == 0)

21   err_quit("child did not terminate");

22  if ((status = WEXITSTATUS(status)) == 0)

23   Read_fd(sockfd[0], &c, 1, &fd);

24  else {

25   errno = status; /* установка значения errno в статус дочернего

                        процесса */

26   fd = -1;

27  }

28  Close(sockfd[0]);

29  return (fd);

30 }

Создание потокового канала

8 Функция socketpair создает потоковый канал. Возвращаются два дескриптора: sockfd[0] и sockfd[1]. Это состояние, которое мы показали на рис. 15.1.

Функции fork и exec

9-16 Вызывается функция fork, после чего дочерний процесс закрывает один конец потокового канала. Номер дескриптора другого конца потокового канала помещается в массив argsockfd, а режим открытия помещается в массив argmode. Мы вызываем функцию snprintf, поскольку аргументы функции exec должны быть символьными строками. Выполняется программа openfile. Функция execl возвращает управление только в том случае, если она встретит ошибку. При удачном выполнении начинает выполняться функция main программы openfile.

Родительский процесс в ожидании завершения дочернего процесса

17-22 Родительский процесс закрывает другой конец потокового канала и вызывает функцию waitpid для ожидания завершения дочернего процесса. Статус завершения дочернего процесса возвращается в переменной status, и сначала мы проверяем, что программа завершилась нормально (то есть не была завершена из-за возникновения какого-либо сигнала). Затем макрос WEXITSTATUS преобразует статус завершения в статус выхода, значение которого должно быть между 0 и 255. Мы вскоре увидим, что если при открытии необходимого файла программой openfile происходит ошибка, то эта программа завершается, причем статус ее завершения равен соответствующему значению переменной errno.

Получение дескриптора

23 Наша функция read_fd, которую мы показываем в следующем листинге, получает дескриптор потокового канала. Кроме получения дескриптора мы считываем 1 байт данных, но ничего с этими данными не делаем.

ПРИМЕЧАНИЕ

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

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

Листинг 15.9. Функция read_fd: получение данных и дескриптора

//lib/read_fd.c

 1 #include "unp.h"

 2 ssize_t

 3 read_fd(int fd, void *ptr, size_t nbytes, int *recvfd)

 4 {

 5  struct msghdr msg;

 6  struct iovec iov[1];

 7  ssize_t n;

 8  int newfd;

 9 #ifdef HAVE_MSGHDR_MSG_CONTROL

10  union {

11   struct cmsghdr cm;

12   char control[CMSG_SPACE(sizeof(int))];

13  } control_un;

14  struct cmsghdr *cmptr;

15  msg.msg_control = control_un.control;

16  msg.msg_controllen = sizeof(control_un.control);

17 #else

18  msg.msg_accrights = (caddr_t)&newfd;

19  msg.msg_accrightslen = sizeof(int);

20 #endif

21  msg.msg_name = NULL;

22  msg.msg_namelen = 0;

23  iov[0].iov_base = ptr;

24  iov[0].iov_len = nbytes;

25  msg.msg_iov = iov;

26  msg.msg_iovlen = 1;

27  if ((n = recvmsg(fd, &msg, 0)) <= 0)

28   return (n);

29 #ifdef HAVE_MSGHDR_MSG_CONTROL

30  if ((cmptr = CMSG_FIRSTHDR(&msg)) != NULL &&

31   mptr->cmsg_len == CMSG_LEN(sizeof(int))) {

32   if (cmptr->cmsg_level != SOL_SOCKET)

33    err_quit("control level != SOL_SOCKET");

34   if (cmptr->cmsg_type != SCM_RIGHTS)

35    err_quit("control type != SCM_RIGHTS");

36   *recvfd = *((int*)CMSG_DATA(cmptr));

37  } else

38   *recvfd = -1; /* дескриптор не был передан */

39 #else

40  if (msg.msg_accrightslen == sizeof(int))

41   *recvfd = newfd;

42  else

43   *recvfd = -1; /* дескриптор не был передан */

44 #endif

45  return (n);

46 }

8-26 Эта функция должна работать с обеими версиями функции recvmsg: с элементом msg_control и с элементом msg_accrights. Наш заголовочный файл config.h (см. листинг Г.2) определяет константу HAVE_MSGHDR_MSG_CONTROL, если поддерживается версия функции recvmsg с msg_control.

Проверка выравнивания буфера msg_control

10-13 Буфер msg_control должен быть выровнен в соответствии со структурой msghdr. Просто выделить в памяти массив типа char недостаточно. Здесь мы объявляем объединение, состоящее из структуры cmsghdr и символьного массива, что гарантирует необходимое выравнивание массива. Возможно и другое решение — вызвать функцию malloc, но это потребует освобождения памяти перед завершением функции.

27-45 Вызывается функция recvmsg. Если возвращаются вспомогательные данные, их формат будет таким, как показано на рис. 14.4. Мы проверяем, верны ли длина, уровень и тип, затем получаем вновь созданный дескриптор и возвращаем его через указатель вызывающего процесса recvfd. Макрос CMSG_DATA возвращает указатель на элемент cmsg_data объекта вспомогательных данных как указатель на элемент типа unsigned char. Мы преобразуем его к указателю на элемент типа int и получаем целочисленный дескриптор, на который указывает этот указатель.

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

В листинге 15.10 показана программа openfile. Она получает три аргумента командной строки, которые должны быть переданы, и вызывает обычную функцию open.

Листинг 15.10. Программа openfile: открытие файла и передача дескриптора обратно

//unixdomain/openfile.c

 1 #include "unp.h"

 2 int

 3 main(int argc, char **argv)

 4 {

 5  int fd;

 6  ssize_t n;

 7  if (argc != 4)

 8   err_quit("openfile ");

 9  if ((fd = open(argv[2], atoi(argv[3]))) < 0)

10   exit((errno > 0) ? errno : 255);

11  if ((n = write_fd(atoi(argv[1]), "", 1, fd)) < 0)

12   exit((errno > 0) ? errno : 255);

13  exit(0);

14 }

Аргументы командной строки

6-7 Поскольку два из трех аргументов командной строки были превращены в символьные строки функцией my_open, они преобразуются обратно в целые числа при помощи функции atoi.

Открытие файла

9-10 Файл открывается с помощью функции open. Если встречается ошибка, статус завершения этого процесса содержит значение переменной errno, соответствующее ошибке функции open.

Передача дескриптора обратно

11-12 Дескриптор передается обратно функцией write_fd, которую мы покажем в следующем листинге. Затем этот процесс завершается, но ранее в этой главе мы сказали, что отправляющий процесс может закрыть переданный дескриптор (это происходит, когда мы вызываем функцию exit), поскольку ядро знает, что дескриптор находится в состоянии передачи («в полете»), и оставляет его открытым для принимающего процесса.

ПРИМЕЧАНИЕ

Статус выхода должен лежать в пределах от 0 до 255. Максимальное значение переменной errno — около 150. Альтернативный способ, при котором не требуется, чтобы значение переменной errno было меньше 256, заключается в том, чтобы передать обратно указание на ошибку в виде обычных данных при вызове функции sendmsg.

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

Листинг 15.11. Функция write_fd: передача дескриптора при помощи вызова функции sendmsg

//lib/write_fd.c

 1 #include "unp.h"

 2 ssize_t

 3 write_fd(int fd, void *ptr, size_t nbytes, int sendfd)

 4 {

 5  struct msghdr msg;

 6  struct iovec iov[1];

 7 #ifdef HAVE_MSGHDR_MSG_CONTROL

 8  union {

 9   struct cmsghdr cm;

10   char control[CMSG_SPACE(sizeof(int))];

11  } control_un;

12  struct cmsghdr *cmptr;

13  msg.msg_control = control_un.control;

14  msg.msg_controllen = sizeof(control_un.control);

15  cmptr = CMSG_FIRSTHDR(&msg);

16  cmptr->cmsg_len = CMSG_LEN(sizeof(int));

17  cmptr->cmsg_level = SOL_SOCKET;

18  cmptr->cmsg_type = SCM_RIGHTS;

19  *((int*)CMSG_DATA(cmptr)) = sendfd;

20 #else

21  msg.msg_accrights = (caddr_t)&sendfd;

22  msg.msg_accrightslen = sizeof(int);

23 #endif

24  msg.msg_name = NULL;

25  msg.msg_namelen = 0;

26  iov[0].iov_base = ptr;

27  iov[0].iov_len = nbytes;

28  msg.msg_iov = iov;

29  msg.msg_iovlen = 1;

30  return (sendmsg(fd, &msg, 0));

31 }

Как и в случае функции read_fg, эта функция обрабатывает либо вспомогательные данные, либо права доступа, которые предшествовали вспомогательным данным в более ранних реализациях. В любом случае инициализируется структура msghdr и затем вызывается функция sendmsg.

В разделе 28.7 мы приводим пример передачи дескриптора, в котором участвуют неродственные (unrelated) процессы, а в разделе 30.9 — пример, где задействованы родственные процессы. В них мы будем использовать функции read_fd и write_fd, которые только что описали.

На рис. 14.4 мы показали другой тип информации, передаваемой через доменный сокет Unix в виде вспомогательных данных: информацию об отправителе, которая передается с помощью структуры cmsgcred, определяемой путем включения заголовочного файла . Упаковка и формат данных зависят от операционной системы. Такая возможность появилась только в BSD/OS 2.1. Мы описываем FreeBSD, а прочие варианты Unix во многом подобны ей (проблема обычно состоит в выборе структуры, которую следует использовать для передачи данных). Рассказ об этой возможности мы считаем необходимым, поскольку это важное, хотя и простое дополнение доменных протоколов Unix. Когда клиент и сервер связываются с помощью этих протоколов, серверу часто бывает необходим способ точно узнать, кто является клиентом, чтобы убедиться, что клиент имеет право запрашивать определенный сервис.

struct fcred {

 uid_t fc_ruid;            /* действующий идентификатор пользователя */

 gid_t fc_rgid;            /* действующий групповой идентификатор */

 char  fc_login[MAXLOGNAME]; /* имя setlogin() */

 uid_t fc_uid;             /* идентификатор пользователя */

 short fc_ngroups;         /* количество групп */

 gid_t fc_groups[NGROUPS]; /* дополнительные групповые идентификаторы */

};

#define fc_gid fc_groups[0] /* групповой идентификатор */

Обычно MAXLONGNAME и NGROUPS имеют значение 16. Значение fc_ngroups равно как минимум 1, а первым элементом массива является идентификатор группы.

Эта информация всегда доступна через доменный сокет Unix, хотя отправителю часто приходится принимать дополнительные меры для обеспечения ее отправки вместе с данными, и получателю также приходится выполнять некоторые действия (например, устанавливать параметры сокета). В системе FreeBSD получатель может обойтись вызовом recvmsg с достаточно большим буфером для вспомогательных данных, чтобы туда поместились идентифицирующие данные (листинг 15.12). Однако отправитель обязан включить структуру cmsgcred при отправке данных посредством sendmsg. Хотя включение структуры осуществляется отправителем, заполняется она ядром. Благодаря этому передача идентифицирующих данных через доменный сокет Unix является надежным способом проверки клиента.

Пример

В качестве примера передачи идентифицирующих данных мы изменим наш потоковый доменный сервер Unix, так чтобы он запрашивал идентифицирующие данные клиента. В листинге 15.12 показана новая функция, read_cred, аналогичная функции read, но возвращающая также структуру fcred, содержащую идентифицирующие данные отправителя.

Листинг 15.12. Функция read_cred: чтение и возвращение идентифицирующих данных отправителя

//unixdomain/readcred.c

 1 #include "unp.h"

 2 #define CONTROL_LEN (sizeof(struct cmsghdr) + sizeof(struct cmsgcred))

 3 ssize_t

 4 read_cred(int fd, void *ptr, size_t nbytes, struct cmsgcred *cmsgcredptr)

 5 {

 6  struct msghdr msg;

 7  struct iovec iov[1];

 8  char control[CONTROL_LEN];

 9  int n;

10  msg.msg_name = NULL;

11  msg.msg_namelen = 0;

12  iov[0].iov_base = ptr;

13  iov[0].iov_len = nbytes;

14  msg.msg_iov = iov;

15  msg.msg_iovlen = 1;

16  msg.msg_control = control;

17  msg.msg_controllen = sizeof(control);

18  msg.msg_flags = 0;

19  if ((n = recvmsg(fd, &msg, 0)) < 0)

20   return(n);

21  cmsgcredptr->cmcred_ngroups = 0; /* идентифицирующие данные не получены */

22  if (cmsgcredptr && msg.msg_controllen > 0) {

23   struct cmsghdr *cmptr = (struct cmsghdr*)control;

24   if (cmptr->cmsg_len < CONTROL_LEN)

25    err_quit("control length = %d", cmptr->cmsg_len);

26   if (cmptr->cmsg_level != SOL_SOCKET)

27    err_quit("control level != SOL_SOCKET");

28   if (cmptr->cmsg_type != SCM_CREDS)

29    err_quit("control type != SCM_CREDS");

30   memcpy(cmsgcredptr, CMSG_DATA(cmptr), sizeof(struct cmsgcred));

31  }

32  return(n);

33 }

3-4 Первые три аргумента идентичны аргументам функции read, а четвертый аргумент — это указатель на структуру cmsgcred, которая будет заполнена.

22-31 Если данные были переданы, проверяются длина, уровень и тип вспомогательных данных, и результирующая структура копируется обратно вызывающему процессу. Если никаких идентифицирующих данных не было передано, мы обнуляем структуру. Поскольку число групп (cmcred_ngroups) всегда равно 1 или больше, нулевое значение указывает вызывающему процессу, что ядро не возвратило никаких идентифицирующих данных.

Функция main для нашего эхо-сервера (см. листинг 15.3) остается неизменной. В листинге 15.13 показана новая версия функции str_echo, полученная путем модификации листинга 5.2. Эта функция вызывается дочерним процессом после того, как родительский процесс принял новое клиентское соединение и вызвал функцию fork.

Листинг 15.13. Функция str_echo, запрашивающая идентифицирующие данные клиента

//unixdomain/strecho.c

 1 #include "unp.h"

 2 ssize_t read_cred(int, void*, size_t, struct cmsgcred*);

 3 void

 4 str_echo(int sockfd)

 5 {

 6  ssize_t n;

 7  int i;

 8  char buf[MAXLINE];

 9  struct cmsgcred cred;

10 again:

11  while ((n = read_cred(sockfd, buf, MAXLINE, &cred)) > 0) {

12   if (cred.cmcred_ngroups == 0) {

13    printf("(no credentials returned)\n");

14   } else {

15    printf("PID of sender = %d\n", cred.cmcred_pid);

16    printf("real user ID = %d\n", cred.cmcred_uid);

17    printf("real group ID = %d\n", cred.cmcred_gid);

18    printf("effective user ID = %d\n", cred.cmcred_euid);

19    printf("%d groups:", cred.cmcred_ngroups - 1);

20    for (i = 1; i < cred.cmcred_ngroups; i++)

21     printf(" %d", cred.cmcred_groups[i]);

22    printf("\n");

23   }

24   Writen(sockfd, buf, n);

25  }

26  if (n < 0 && errno == EINTR)

27   goto again;

28  else if (n < 0)

29   err_sys("str_echo: read error");

30 }

11-23 Если идентифицирующие данные возвращаются, они выводятся.

24-25 Оставшаяся часть цикла не меняется. Этот код считывает строки от клиента и затем отправляет их обратно клиенту.

Наш клиент, представленный в листинге 15.4, остается практически неизменным. Мы добавляем передачу пустой структуры cmsgcred при вызове sendmsg, которая заполняется ядром.

Перед запуском клиента определим свои личные данные командой id:

freebsd % id

uid=1007(andy) gid=1007(andy) groups=1007(andy), 0(wheel)

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

freebsd % unixstrserv02

PID of sender = 26881

real user ID = 1007

real group ID = 1007

effective user ID = 1007

2 groups: 1007 0

Информация выводится только после отправки клиентом данных серверу. Мы видим, что сведения соответствуют тем, которые были получены командой id.

Мы снова возвращаемся к нашей функции str_cli, которую мы обсуждали в разделах 5.5 и 6.4. Последняя ее версия, задействующая функцию select, продолжает использовать блокируемый ввод-вывод. Например, если в стандартном устройстве ввода имеется некоторая строка, мы читаем ее с помощью функции fgets и затем отправляем серверу с помощью функции writen. Но вызов функции writen может вызвать блокирование процесса, если буфер отправки сокета полон. В то время как мы заблокированы в вызове функции writen, данные могут быть доступны для чтения из приемного буфера сокета. Аналогично, когда строка ввода доступна из сокета, мы можем заблокироваться в последующем вызове функции fputs, если стандартный поток вывода работает медленнее, чем сеть. Наша цель в данном разделе — создать версию этой функции, использующую неблокируемый ввод-вывод. Блокирование будет предотвращено, благодаря чему в это время мы сможем сделать еще что-то полезное.

К сожалению, добавление неблокируемого ввода-вывода значительно усложняет управление буфером функции, поэтому мы будем представлять функцию частями. Мы также заменим вызовы функций из стандартной библиотеки ввода-вывода на обычные read и write. Это даст возможность отказаться от функций стандартной библиотеки ввода-вывода с неблокируемыми дескрипторами, так как их применение может привести к катастрофическим последствиям.

Мы работаем с двумя буферами: буфер to содержит данные, направляющиеся из стандартного потока ввода к серверу, а буфер fr — данные, приходящие от сервера в стандартный поток вывода. На рис. 16.1 представлена организация буфера to и указателей в буфере.

Рис. 16.1. Буфер, содержащий данные из стандартного потока ввода, идущие к сокету

Указатель toiptr указывает на следующий байт, в который данные могут быть считаны из стандартного потока ввода. Указатель tooptr указывает на следующий байт, который должен быть записан в сокет. Число байтов, которое может быть считано из стандартного потока ввода, равно &to[MAXLINE] минус toiptr. Как только значение tooptr достигает toiptr, оба указателя переустанавливаются на начало буфера.

На рис. 16.2 показана соответствующая организация буфера fr. В листинге 16.1 представлена первая часть функции.

Рис. 16.2. Буфер, содержащий данные из сокета, идущие к стандартному устройству вывода

Листинг 16.1. Функция str_cli: первая часть, инициализация и вызов функции

//nonblock/strclinonb.c

 1 #include "unp.h"

 2 void

 3 str_cli(FILE *fp, int sockfd)

 4 {

 5  int maxfdp1, val, stdineof;

 6  ssize_t n, nwritten;

 7  fd_set rset, wset;

 8  char to[MAXLINE], fr[MAXLINE];

 9  char *toiptr, *tooptr, *friptr, *froptr;

10  val = Fcntl(sockfd, F_GETFL, 0);

11  Fcntl(sockfd, F_SETFL, val | O_NONBLOCK);

12  val = Fcntl(STDIN_FILENO, F_SETFL, 0);

13  Fcntl(STDIN_FILENO, F_SETFL, val | O_NONBLOCK);

14  val = Fcntl(STDOUT_FILENO, F_SETFL, 0);

15  Fcntl(STDOUT_FILENO, F_SETFL, val | O_NONBLOCK);

16  toiptr = tooptr = to; /* инициализация указателей буфера */

17  friptr = froptr = fr;

18  stdineof = 0;

19  maxfdp1 = max(max(STDIN_FILENO, STDOUT_FILENO), sockfd) + 1;

20  for (;;) {

21   FD_ZERO(&rset);

22   FD_ZERO(&wset);

23   if (stdineof == 0 && toiptr < &to[MAXLINE])

24     FD_SET(STDIN_FILENO, &rset); /* чтение из стандартного потока

                                       ввода */

25   if (friptr < &fr[MAXLINE])

26    FD_SET(sockfd, &rset); /* чтение из сокета */

27   if (tooptr != toiptr)

28    FD_SET(sockfd, &wset); /* данные для записи в сокет */

29   if (froptr != friptr)

30    FD_SET(STDOUT_FILENO, &wset); /* данные для записи в стандартный

                                       поток вывода */

31   Select(maxfdp1, &rset, &wset, NULL, NULL);

Установка неблокируемых дескрипторов

10-15 Все три дескриптора делаются неблокируемыми при помощи функции fcntl: сокет в направлении к серверу и от сервера, стандартный поток ввода и стандартный поток вывода.

Инициализация указателей буфера

16-19 Инициализируются указатели в двух буферах и вычисляется максимальный дескриптор. Это значение, увеличенное на единицу, будет использоваться в качестве первого аргумента функции select.

Основной цикл: подготовка к вызову функции select

20 Как и в случае первой версии этой функции, показанной в листинге 6.2, основной цикл функции содержит вызов функции select, за которой следуют отдельные проверки различных интересующих нас условий.

Подготовка интересующих нас дескрипторов

21-30 Оба набора дескрипторов обнуляются и затем в каждом наборе включается не более двух битов. Если мы еще не прочитали конец файла из стандартного потока ввода и есть место как минимум для 1 байта данных в буфере to, то в наборе флагов чтения включается бит, соответствующий стандартному потоку ввода. Если есть место как минимум для 1 байта данных в буфере fr, то в наборе флагов чтения включается бит, соответствующий сокету. Если есть данные для записи в сокет в буфере to, то в наборе флагов записи включается бит, соответствующий сокету. Наконец если в буфере fr есть данные для отправки в стандартный поток вывода, то в наборе флагов записи включается бит, соответствующий этому стандартному потоку.

Вызов функции select

31 Вызывается функция select, ожидающая, когда одно из четырех условий станет истинным. Для этой функции мы не задаем тайм-аута.

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

Листинг 16.2. Функция str_cli: вторая часть, чтение из стандартного потока ввода или сокета

//nonblock/strclinonb.c

32   if (FD_ISSET(STDIN_FILENO, &rset)) {

33    if ((n = read(STDIN_FILENO, toiptr, &to[MAXLINE] - toiptr)) < 0) {

34     if (errno != EWOULDBLOCK)

35      err_sys("read error on stdin");

36    } else if (n == 0) {

37     fprintf(stderr, "%s: EOF on stdin\n", gf_time());

38     stdineof = 1; /* с stdin все сделано */

39     if (tooptr == toiptr)

40      Shutdown(sockfd, SHUT_WR); /* отсылаем FIN */

41    } else {

42     fprintf(stderr, "%s: read %d bytes from stdin\n", gf_time(),

43      n);

44     toiptr += n; /* только что полученное из функции read число */

45     FD_SET(sockfd, &wset); /* включаем бит в наборе чтения */

46    }

47   }

48   if (FD_ISSET(sockfd, &rset)) {

49    if ((n = read(sockfd, friptr, &fr[MAXLINE] - friptr)) < 0) {

50     if (errno != EWOULDBLOCK)

51      err_sys("read error on socket");

52    } else if (n == 0) {

53     fprintf(stderr, "%s: EOF on socket\n", gf_time());

54     if (stdineof)

55      return; /* нормальное завершение */

56     else

57      err_quit("str_cli: server terminated prematurely");

58    } else {

59     fprintf(stderr, "%s: read %d bytes from socket\n",

60      gf_time(), n);

61     friptr += n; /* только что полученное из функции read число */

62     FD_SЕТ(STDOUT_FILЕNO, &wset); /* включаем бит в наборе

                                        чтения */

63    }

64   }

Чтение из стандартного потока ввода с помощью функции read

32-33 Если стандартный поток ввода готов для чтения, мы вызываем функцию read. Третий ее аргумент — это количество свободного места в буфере to.

Обработка ошибки

34-35 Если происходит ошибка EWOULDBLOCK, мы ничего не предпринимаем. Обычно эта ситуация — когда функция select сообщает нам о том, что дескриптор готов для чтения, а функция read возвращает ошибку EWOULDBLOCK — не должна возникать, но тем не менее мы ее обрабатываем.

Возвращение конца файла функцией read

36-40 Если функция read возвращает нуль, мы закончили со стандартным потоком ввода. Флаг stdineof установлен. Если в буфере to больше нет данных для отправки (tooptr равно toiptr), функция shutdown отправляет серверу сегмент FIN. Если в буфере to еще есть данные для отправки, сегмент FIN не может быть отправлен до тех пор, пока содержимое буфера не будет записано в сокет.

ПРИМЕЧАНИЕ

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

Возвращение данных функцией read

41-45 Когда функция read возвращает данные, мы увеличиваем на единицу toiptr. Мы также включаем бит, соответствующий сокету, в наборе флагов записи, чтобы позже при проверке этого бита в цикле он был включен и тем самым инициировалась бы попытка записи в сокет с помощью функции write.

ПРИМЕЧАНИЕ

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

Чтение из сокета с помощью функции read

48-64 Эти строки кода аналогичны выражению if, только что описанному для случая, когда стандартный поток ввода готов для чтения. Если функция read возвращает ошибку EWOULDBLOCK, ничего не происходит. Если мы встречаем признак конца файла, присланный сервером, это нормально, когда мы уже получили признак конца файла в стандартном потоке ввода. Но иначе это будет ошибкой, означающей преждевременное завершение работы сервера (Server terminated prematurely). Если функция read возвращает некоторые данные, friptr увеличивается на единицу и в наборе флагов записи включается бит для стандартного потока вывода, с тем чтобы попытаться записать туда данные в следующей части функции.

В листинге 16.3 показана последняя часть нашей функции.

Листинг 16.3. Функция str_cli: третья часть, запись в стандартный поток вывода или сокет

//nonblock/strclinonb.c

65   if (FD_ISSET(STDOUT_FILENO, &wset) && ((n = friptr - froptr) > 0)) {

66    if ((nwritten = write(STDOUT_FILENO, froptr, n)) < 0) {

67     if (errno != EWOULDBLOCK)

68      err_sys("write error to stdout");

69    } else {

70     fprintf(stderr, "%s: wrote %d bytes to stdout\n",

71      gf_time(), nwritten);

72     froptr += nwritten; /* только что полученное из функции write

                              число */

73     if (froptr == friptr)

74      froptr = friptr - fr; /* назад к началу буфера */

75    }

76   }

77   if (FD_ISSET(sockfd, &wset) && ((n - toiptr - tooptr) > 0)) {

78    if ((nwritten = write(sockfd, tooptr, n)) < 0) {

79     if (errno != EWOULDBLOCK)

80      err_sys("write error to socket");

81    } else {

82     fprintf(stderr, "%s: wrote %d bytes to socket\n",

83      gf_time(), nwritten);

84     tooptr += nwritten; /* только что полученное из функции write

                              число */

85     if (tooptr == toiptr) {

86      toiptr - tooptr = to; /* назад к началу буфера */

87      if (stdineof)

88       Shutdown(sockfd, SHUT_WR); /* посылаем FIN */

89     }

90    }

91   }

92  }

93 }

Запись в стандартный поток вывода с помощью функции write

65-68 Если есть возможность записи в стандартный поток вывода и число байтов для записи больше нуля, вызывается функция write. Если возвращается ошибка EWOULDBLOCK, ничего не происходит. Обратите внимание, что это условие возможно, поскольку код в конце предыдущей части функции включает бит в наборе флагов записи для стандартного потока вывода, когда не известно, успешно выполнилась функция write или нет.

Успешное выполнение функции write

68-74 Если функция write выполняется успешно, froptr увеличивается на число записанных байтов. Если указатель вывода стал равен указателю ввода, оба указателя переустанавливаются на начало буфера.

Запись в сокет с помощью функции write

76-90 Эта часть кода аналогична коду, только что описанному для записи в стандартный поток вывода. Единственное отличие состоит в том, что когда указатель вывода доходит до указателя ввода, не только оба указателя переустанавливаются в начало буфера, но и появляется возможность отправить серверу сегмент FIN.

Теперь мы проверим работу этой функции и операций неблокируемого ввода-вывода. В листинге 16.4 показана наша функция gf_time, вызываемая из функции str_cli.

Листинг 16.4. Функция gf_time: возвращение указателя на строку времени

//lib/gf_time.c

 1 #include "unp.h"

 2 #include

 3 char*

 4 gf_time(void)

 5 {

 6  struct timeval tv;

 7  static char str[30];

 8  char *ptr;

 9  if (gettimeofday(&tv, NULL) < 0)

10   err_sys("gettimeofday error");

11  ptr = ctime(&tv.tv_sec);

12  strcpy(str, &ptr[11]);

13  /* Fri Sep 13 00:00:00 1986\n\0 */

14  /* 0123456789012345678901234 5 */

15  snprintf(str + 8, sizeof(str) - 8, ".%06ld", tv.tv_usec);

15  return (str);

17 }

Эта функция возвращает строку, содержащую текущее время с точностью до микросекунд, в таком формате:

12:34:56.123456

Здесь специально используется тот же формат, что и для отметок времени, которые выводятся программой tcpdump. Обратите внимание, что все вызовы функции fprintf в нашей функции str_cli записывают данные в стандартный поток сообщений об ошибках, позволяя нам отделить данные стандартного потока вывода (строки, отраженные сервером) от наших диагностических данных. Затем мы можем запустить наш клиент и функцию tcpdump, получить эти диагностические данные вместе с результатом функции tcpdump и отсортировать вместе два вида выходных данных в порядке их получения. Это позволит нам увидеть, что происходит в нашей программе, и соотнести это с действиями TCP.

Например, сначала мы запускаем функцию tcpdump на нашем узле solaris, собирая только сегменты TCP, идущие к порту 7 или от него (эхо-сервер), и сохраняем выходные данные в файле, который называется tcpd:

solaris % tcpdump -w tcpd tcp and port 7

Затем мы запускаем клиент TCP на этом узле и указываем сервер на узле linux:

solaris % tcpcli02 192.168.1.10 < 2000.lines > out 2> diag

Стандартный поток ввода — это файл 2000.lines, тот же файл, что мы использовали для листинга 6.2. Стандартный поток вывода перенаправляется в файл out, а стандартный поток сообщений об ошибках — в файл diag. По завершении мы запускаем:

solaris % diff 2000.lines out

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

Листинг 16.5. Отсортированный вывод функции tcpdump и данных диагностики

solaris % tcpdump -r tcpd -N | sort diag -

10:18:34.486392 solaris.33621 > linux.echo: S 1802738644:1802738644(0) win 8760

10:18:34.488278 linux.echo > solaris.33621: S 3212986316 3212986316(0) ack 1802738645 win 8760

10:18:34.488490 solaris.33621 > linux.echo: . ack 1 win 8760

10:18:34.491482: read 4096 bytes from stdin

10:18:34.518663 solaris.33621 > linux.echo: P 1461(1460) ack 1 win 8760

10:18:34.519016: wrote 4096 bytes to socket

10:18:34.528529 linux echo > solaris.33621. P 1:1461(1460) ack 1461 win 8760

10:18:34 528785 solaris.33621 > linux.echo: . 1461 2921(1460) ack 1461 win 8760

10:18:34.528900 solaris.33621 > linux echo: P 2921:4097(1176) ack 1461 win 8760

10:18:34.528958 solaris 33621 > linux.echo: ack 1461 win 8760

10:18:34.536193 linux echo: > solaris.33621: . 1461:2921(1460) ack 4097 win 8760

10:18:34.536697 linux.echo: > solaris.33621: P 2921.3509(588) ack 4097 win 8760

10:18.34.544636: read 4096 bytes from stdin 10:18:34.568505: read 3508 bytes from socket

10:18:34.580373 solaris 33621 > linux.echo: . ack 3509 win 8760

10:18:34.582244 linux.echo > solaris.33621: P 3509.4097(588) ack 4097 win 8760

10:18:34.593354: wrote 3508 bytes to stdout

10:18:34.617272 solaris.33621 > linux.echo: P 4097.5557(1460) ack 4097 win 8760

10:18:34.617610 solaris 33621 > linux.echo: P 5557:7017(1460) ack 4097 win 8760

10:18:34.617908 solaris.33621 > linux.echo: P 7017.8193(1176) ack 4097 win 8760

10:18:34.618062: wrote 4096 bytes to socket

10:18:34.623310 linux.echo > solaris.33621: . ack 8193 win 8760

10:18:34.626129 linux.echo > solaris.33621: . 4097.5557(1460) ack 8193 win 8760

10:18:34.626339 solaris.33621 > linux.echo: . ack 5557 win 8760

10:18:34.626611 linux.echo > solaris.33621: P 5557:6145(588) ack 8193 win 8760

10:18:34.628396 linux.echo > solaris.33621: 6145:7605(1460) ack 8193 win 8760

10:18:34.643524: read 4096 bytes from stdin 10:18:34.667305. read 2636 bytes from socket

10:18:34.670324 solaris.33621 > linux echo: . ack 7605 win 8760

10:18:34.672221 linux.echo > solaris.33621: P 7605.8193(588) ack 8193 win 8760

10:18:34.691039: wrote 2636 bytes to stdout

Мы удалили записи (DF) из сегментов, отправленных Solaris, означающие, что устанавливается бит DF (он используется для определения величины транспортной MTU).

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

Рис. 16.3. Временная диаграмма событий для примера неблокируемого ввода

На этом рисунке мы не показываем сегменты ACK. Также помните, что если программа выводит сообщение wrote N bytes to stdout (записано N байт в стандартное устройство вывода), это означает, что завершилась функция write, возможно, заставившая TCP отправить один или более сегментов данных.

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

Мы можем рассчитать время выполнения нашей неблокируемой версии, используя тот же файл из 2000 строк и тот же сервер (с периодом RTT, равным 175 мс), что и в разделе 6.7. Теперь время оказалось равным 6,9 с по сравнению с 12,3 с в версии из раздела 6.7. Следовательно, неблокируемый ввод-вывод сокращает общее время выполнения этого примера, в котором файл отправляется серверу.

Более простая версия функции str_cli

Неблокируемая версия функции str_cli, которую мы только что показали, нетривиальна: около 135 строк кода по сравнению с 40 строками версии, использующей функцию select с блокируемым вводом-выводом (см. листинг 6.2), и 20 строками начальной версии, работающей в режиме остановки и ожидания (см. листинг 5.4). Мы знаем, что эффект от удлинения кода в два раза, с 20 до 40 строк оправдывает затраченные усилия, поскольку в пакетном режиме скорость возрастает почти в 30 раз, а применение функции select с блокируемыми дескрипторами осуществляется не слишком сложно. Но будут ли оправданы затраченные усилия при написании приложения, использующего неблокируемый ввод-вывод, с учетом усложнения итогового кода? Нет, ответим мы. Если нам необходимо использовать неблокируемый ввод-вывод, обычно бывает проще разделить приложение либо на процессы (при помощи функции fork), либо на потоки (см. главу 26).

В листинге 16.6 показана еще одна версия нашей функции str_cli, разделяемая на два процесса при помощи функции fork.

Эта функция сразу же вызывает функцию fork для разделения на родительский и дочерний процессы. Дочерний процесс копирует строки от сервера в стандартный поток вывода, а родительский процесс — из стандартного потока ввода серверу, как показано на рис. 16.4.

Рис. 16.4. Функция str_cli, использующая два процесса

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

Листинг 16.6. Версия функции str_cli, использующая функцию fork

//nonblock/strclifork.c

 1 #include "unp.h"

 2 void

 3 str_cli(FILE *fp, int sockfd)

 4 {

 5  pid_t pid;

 6  char sendline[MAXLINE], recvline[MAXLINE];

 7  if ((pid = Fork()) == 0) { /* дочерний процесс: сервер -> stdout */

 8   while (Readline(sockfd, recvline, MAXLINE) > 0)

 9    Fputs(recvline, stdout);

10   kill(getppid(), SIGTERM); /* в случае, если родительский процесс

                                 все еще выполняется */

11   exit(0);

12  }

13  /* родитель: stdin -> сервер */

14  while (Fgets(sendline, MAXLINE, fp) != NULL)

15   Writen(sockfd, sendline, strlen(sendline));

16  Shutdown(sockfd, SHUT_WR); /* конец файла на stdin, посылаем FIN */

17  pause();

18  return;

19 }

Нам нужно снова вспомнить о последовательности завершения соединения. Обычное завершение происходит, когда в стандартном потоке ввода встречается конец файла. Родительский процесс считывает конец файла и вызывает функцию shutdown для отправки сегмента FIN. (Родительский процесс не может вызвать функцию close, см. упражнение 16.1.) Но когда это происходит, дочерний процесс должен продолжать копировать от сервера в стандартный поток вывода, пока он не получит признак конца файла на сокете.

Также возможно, что процесс сервера завершится преждевременно (см. раздел 5.12), и если это происходит, дочерний процесс считывает признак конца файла на сокете. В таком случае дочерний процесс должен сообщить родительскому, что нужно прекратить копирование из стандартного потока ввода в сокет (см. упражнение 16.2). В листинге 16.6 дочерний процесс отправляет родительскому процессу сигнал SIGTERM, в случае, если родительский процесс еще выполняется (см. упражнение 16.3). Другим способом обработки этой ситуации было бы завершение дочернего процесса, и если родительский процесс все еще выполнялся бы к этому моменту, он получил бы сигнал SIGCHLD.

Родительский процесс вызывает функцию pause, когда заканчивает копирование, что переводит его в состояние ожидания того момента, когда будет получен сигнал. Даже если родительский процесс не перехватывает никаких сигналов, он все равно переходит в состояние ожидания до получения сигнала SIGTERM от дочернего процесса. По умолчанию действие этого сигнала — завершение процесса, что вполне устраивает нас в этом примере. Родительский процесс ждет завершения дочернего процесса, чтобы измерить точное время для этой версии функции str_cli. Обычно дочерний процесс завершается после родительского, но поскольку мы измеряем время, используя команду оболочки time, измерение заканчивается, когда завершается родительский процесс.

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

Сравнение времени выполнения различных версий функции str_cli

Итак, мы продемонстрировали четыре различных версии функции str_cli. Для каждой версии мы покажем время, которое потребовалось для ее выполнения, в том числе и для версии, использующей программные потоки (см. листинг 26.1). В каждом случае было скопировано 2000 строк от клиента Solaris к серверу с периодом RTT, равным 175 мс:

■ 354,0 с, режим остановки и ожидания (см. листинг 5.4);

■ 12,3 с, функция select и блокируемый ввод-вывод (см. листинг 6.2);

■ 6,9 с, неблокируемый ввод-вывод (см. листинг 16.1);

■ 8,7 с, функция fork (см. листинг 16.6);

■ 8,5 с, версия с потоками (см. листинг 26.1).

Наша версия с неблокируемым вводом-выводом почти вдвое быстрее версии, использующей блокируемый ввод-вывод с функцией select. Наша простая версия с применением функции fork медленнее версии с неблокируемым вводом- выводом. Тем не менее, учитывая сложность кода неблокируемого ввода-вывода по сравнению с кодом функции fork, мы рекомендуем более простой подход.

В листинге 16.7 показана наша функция connect_nonb, вызывающая неблокируемую функцию connect. Мы заменяем вызов функции connect, имеющийся в листинге 1.1, следующим фрагментом кода:

if (connect_nonb(sockfd, (SA*)&servaddr, sizeof(servaddr), 0) < 0)

err_sys("connect error");

Первые три аргумента являются обычными аргументами функции connect, а четвертый аргумент — это число секунд, в течение которых мы ждем завершения установления соединения. Нулевое значение подразумевает отсутствие тайм- аута для функции select; следовательно, для установления соединения TCP ядро будет использовать свой обычный тайм-аут.

Листинг 16.7. Неблокируемая функция connect

//lib/connect_nonb.c

 1 #include "unp.h"

 2 int

 3 connect_nonb(int sockfd, const SA *saptr, socklen_t salen, int nsec)

 4 {

 5  int flags, n, error;

 6  socklen_t len;

 7  fd_set rset, wset;

 8  struct timeval tval;

 9  flags = Fcntl(sockfd, F_GETFL, 0);

10  Fcntl(sockfd, F_SETFL, flags | O_NONBLOCK);

11  error = 0;

12  if ((n = connect(sockfd, saptr, salen)) < 0)

13   if (errno != EINPROGRESS)

14    return (-1);

15  /* Пока соединение устанавливается, мы можем заняться чем-то другим */

16  if (n == 0)

17   goto done; /* функция connect завершилась немедленно */

18  FD_ZERO(&rset);

19  FDSET(sockfd, &rset);

20  wset = rset;

21  tval.tv_sec = nsec;

22  tval.tv_usec = 0;

23  if ((n = Select(sockfd + 1, &rset, &wset, NULL,

24   nsec ? &tval : NULL)) == 0) {

25   close(sockfd); /* тайм-аут */

26   errno = ETIMEDOUT;

27   return (-1);

28  }

29  if (FD_ISSET(sockfd, &rset) || FD_ISSET(sockfd, &wset)) {

30   len = sizeof(error);

31   if (getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &error, &len) < 0)

32    return (-1); /*в Solaris ошибка, ожидающая обработки */

33  } else

34   err_quit("select error: sockfd not set");

35 done:

36  Fcntl(sockfd, F_SETFL, flags); /* восстанавливаем флаги, задающие статус файла */

37  if (error) {

38   close(sockfd); /* на всякий случай */

39   errno = error;

40   return (-1);

41  }

42  return (0);

43 }

Задание неблокируемого сокета

9-10 Мы вызываем функцию fcntl, которая делает сокет неблокируемым.

11-14 Мы вызываем неблокируемую функцию connect. Ошибка, которую мы ожидаем (EINPROGRESS), указывает на то, что установление соединения началось, но еще не завершилось [128, с. 466]. Любая другая ошибка возвращается вызывающему процессу.

Выполнение других процессов во время установления соединения

15 На этом этапе мы можем делать все, что захотим, ожидая завершения установления соединения.

Проверка немедленного завершения

16-17 Если неблокируемая функция connect возвратила нуль, установление соединения завершилось. Как мы сказали, это может произойти, когда сервер находится на том же узле, что и клиент.

Вызов функции select

18-24 Мы вызываем функцию select и ждем, когда сокет будет готов либо для чтения, либо для записи. Мы обнуляем rset, включаем бит, соответствующий sockfd в этом наборе дескрипторов и затем копируем rset в wset. Это присваивание, возможно, является структурным присваиванием, поскольку обычно наборы дескрипторов представляются как структуры. Далее мы инициализируем структуру timeval и затем вызываем функцию select. Если вызывающий процесс задает четвертый аргумент нулевым (что соответствует использованию тайм-аута по умолчанию), следует задать в качестве последнего аргумента функции select пустой указатель, а не структуру timeval с нулевым значением (означающим, что мы не ждем вообще).

Обработка тайм-аутов

25-28 Если функция select возвращает нуль, это означает, что время таймера истекло, и мы возвращаем вызывающему процессу ошибку ETIMEDOUT. Мы также закрываем сокет, чтобы трехэтапное рукопожатие не продолжалось.

Проверка возможности чтения или записи

29-34 Если дескриптор готов для чтения или для записи, мы вызываем функцию getsockopt, чтобы получить ошибку сокета (SO_ERROR), ожидающую обработки. Если соединение завершилось успешно, это значение будет нулевым. Если при установлении соединения произошла ошибка, это значение является значением переменной errno, соответствующей ошибке соединения (например, ECONNREFUSED, ETIMEDOUT и т.д.). Мы также сталкиваемся с нашей первой проблемой переносимости. Если происходит ошибка, Беркли-реализации функции getsockopt возвращают нуль, а ошибка, ожидающая обработки, возвращается в нашей переменной error. Но в системе Solaris сама функция getsockopt возвращает -1, а переменная errno при этом принимает значение, соответствующее ошибке, ожидающей обработки. В нашем коде обрабатываются оба сценария.

Восстановление возможности блокировки сокета и завершение

36-42 Мы восстанавливаем флаги, задающие статус файла, и возвращаемся. Если наша переменная errno имеет ненулевое значение в результате выполнения функции getsockopt, это значение хранится в переменной errno, и функция возвращает -1.

Как мы сказали ранее, проблемы переносимости для функции connect связаны с различными реализациями сокетов и отключения блокировки. Во-первых, возможно, что установление соединения завершится и придут данные для собеседника до того, как будет вызвана функция select. В этом случае сокет будет готов для чтения и для записи при успешном выполнении функции, как и при неудачном установленном соединении. В нашем коде, показанном в листинге 16.7, этот сценарий обрабатывается при помощи вызова функции getsockopt и проверки на наличие ошибки, ожидающей обработки, для сокета.

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

1. Вызвать функцию getpeername вместо функции getsockopt. Если этот вызов окажется неудачным и возвратится ошибка ENOTCONN, значит, соединение не было установлено, и чтобы получить ошибку, ожидающую обработки, следует вызвать для сокета функцию getsockopt с SO_ERROR.

2. Вызвать функцию read с нулевым значением аргумента length. Если выполнение функции read окажется неудачным, функция connect выполнилась неудачно, и переменная errno из функции read при этом указывает на причину неудачной попытки установления соединения. Если соединение успешно установлено, функция read возвращает нуль.

3. Снова вызвать функцию connect. Этот вызов окажется неудачным, и если ошибка — EISCONN, сокет уже присоединен, а значит, первое соединение завершилось успешно.

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

Прерванная функция connect

Что происходит, если наш вызов функции connect на обычном блокируемом сокете прерывается, скажем, перехваченным сигналом, прежде чем завершится трехэтапное рукопожатие TCP? Если предположить, что функция connect не перезапускается автоматически, то она возвращает ошибку EINTR. Но мы не можем снова вызвать функцию connect, чтобы добиться завершения установления соединения. Это приведет к ошибке EADDRINUSE.

Все, что требуется сделать в этом сценарии, — вызвать функцию select, так, как мы делали в этом разделе для неблокируемой функции connect. Тогда функция select завершится, если соединение успешно устанавливается (делая сокет доступным для записи) или если попытка соединения неудачна (сокет становится доступен для чтения и для записи).

Первое практическое использование неблокируемой функции connect относится к веб-клиенту Netscape (см. раздел 13.4 [112]). Клиент устанавливает соединение HTTP с веб-сервером и попадает на домашнюю страницу. На этой странице часто присутствуют ссылки на другие веб-страницы. Вместо того чтобы получать последовательно по одной странице за один раз, клиент может получить сразу несколько страниц, используя неблокируемые функции connect. На рис. 16.5 показан пример установления множества параллельных соединений. Сценарий, изображенный слева, показывает все три соединения, устанавливаемые одно за другим. Мы считаем, что первое соединение занимает 10 единиц времени, второе — 15, а третье — 4, что в сумме дает 29 единиц времени.

Рис. 16.5. Установление множества параллельных соединений

В центре рисунка показан сценарий, при котором мы выполняем два параллельных соединения. В момент времени 0 запускаются первые два соединения, а когда первое из них устанавливается, мы запускаем третье. Общее время сократилось почти вдвое и равно 15, а не 29 единицам времени, но учтите, что это идеальный случай. Если параллельные соединения совместно используют общий канал связи (допустим, клиент использует модем для соединения с Интернетом), то каждое из этих соединений конкурирует с другими за обладание ограниченными ресурсами этого канала связи, и время установления каждого соединения может возрасти. Например, время 10 может дойти до 15, 15 — до 20, а время 4 может превратиться в 6. Тем не менее общее время будет равно 21 единице, то есть все равно меньше, чем в последовательном сценарии.

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

При работе с веб-клиентами первое соединение устанавливается само по себе, за ним следуют соединения по ссылкам, обнаруженным в данных от первого соединения. Мы показываем это на рис. 16.6.

Рис. 16.6. Установление первого соединения, а затем множества параллельных соединений

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

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

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

solaris % web % www.foobar.com / image1.gif image2.gif \

 image3.gif image4.gif image5.gif \

 image6.gif image7.gif

Аргументы командной строки задают три одновременных соединения, имя узла сервера, имя файла домашней страницы (/ обозначает корневой каталог сервера) и семь файлов, которые затем нужно прочитать (в нашем примере это файлы с изображениями в формате GIF). Обычно на эти семь файлов имеются ссылки с домашней страницы, и чтобы получить их имена, веб-клиент читает домашнюю страницу и обрабатывает код HTML. Чтобы не усложнять этот пример разбором кода HTML, мы просто задаем имена файлов в командной строке.

Это большой пример, поэтому мы будем показывать его частями. В листинге 16.8 представлен наш заголовочный файл web.h, который включен во все файлы.

Листинг 16.8. Заголовок web.h

//nonblock/web.h

 1 #include "unp.h"

 2 #define MAXFILES 20

 3 #define SERV "80" /* номер порта или имя службы */

 4 struct file {

 5  char *f_name; /* имя файла */

 6  char *f_host; /* имя узла или адрес IPv4/IPv6 */

 7  int  f_fd;    /* дескриптор */

 8  int  f_flags; /* F_xxx определены ниже */

 9 } file[MAXFILES];

10 #define F_CONNECTING 1 /* connect() в процессе выполнения */

11 #define F_READING 2 /* соединение установлено; происходит считывание */

12 #define F_DONE 4 /* все сделано */

13 #define GET_CMD "GET %s HTTP/1.0\r\n\r\n"

14 /* глобальные переменные */

15 int nconn, nfiles, nlefttoconn, nlefttoread, maxfd;

16 fd_set rset, wset;

17 /* прототипы функций */

18 void home_page(const char*, const char*);

19 void start_connect (struct file*);

20 void write_get_cmd(struct file*);

Задание структуры file

2-13 Программа считывает некоторое количество (не более MAXFILES) файлов с веб-сервера. Структура file содержит информацию о каждом файле: его имя (копируется из аргумента командной строки), имя узла или IP-адрес сервера, с которого читается файл, дескриптор сокета, используемый для этого файла, и набор флагов, которые указывают, что мы делаем с этим файлом (устанавливаем соединение для получения файла или считываем файл).

Определение глобальных переменных и прототипов функций

14-20 Мы определяем глобальные переменные и прототипы для наших функций, которые мы вскоре опишем.

Листинг 16.9. Первая часть программы одновременного выполнения функций connect: глобальные переменные и начало функции main

//nonblock/web.c

 1 #include "web.h"

 2 int

 3 main(int argc, char **argv)

 4 {

 5  int i, fd, n, maxnconn, flags, error;

 6  char buf[MAXLINE];

 7  fd_set rs, ws;

 8  if (argc < 5)

 9   err_quit("usage: web <#conns> ...");

10  maxnconn = atoi(argv[1]);

11  nfiles = min(argc - 4, MAXFILES);

12  for (i = 0; i < nfiles; i++) {

13   file[i].f_name = argv[i + 4];

14   file[i].f_host = argv[2];

15   file[i].f_flags = 0;

16  }

17  printf("nfiles = %d\n", nfiles);

18  home_page(argv[2], argv[3]);

19  FD_ZERO(&rset);

20  FD_ZERO(&wset);

21  maxfd = -1;

22  nlefttoread = nlefttoconn = nfiles;

23  nconn = 0;

Обработка аргументов командной строки

11-17 Структуры file заполняются соответствующей информацией из аргументов командной строки.

Чтение домашней страницы

18 Функция home_page, которую мы показываем в следующем листинге, создает соединение TCP, посылает команду серверу и затем читает домашнюю страницу. Это первое соединение, которое выполняется самостоятельно, до того как мы начнем устанавливать параллельные соединения.

Инициализация глобальных переменных

19-23 Инициализируются два набора дескрипторов, по одному для чтения и для записи. maxfd — это максимальный дескриптор для функции select (который мы инициализируем значением -1, поскольку дескрипторы неотрицательны), nlefttoread — число файлов, которые осталось прочитать (когда это значение становится нулевым, чтение заканчивается), nlefttoconn — это количество файлов, для которых пока еще требуется соединение TCP, a nconn — это число соединений, открытых в настоящий момент (оно никогда не может превышать первый аргумент командной строки).

В листинге 16.10 показана функция home_page, вызываемая один раз, когда начинается выполнение функции main.

Листинг 16.10. Функция home_page

//nonblock/home_page.c

 1 #include "web.h"

 2 void

 3 home_page(const char *host, const char *fname)

 4 {

 5  int fd, n;

 6  char line[MAXLINE];

 7  fd = Tcp_connect(host, SERV); /* блокируемая функция connect() */

 8  n = snprintf(line, sizeof(line), GET_CMD, fname);

 9  Writen(fd, line, n);

10  for (;;) {

11   if ((n = Read(fd, line, MAXLINE)) == 0)

12    break; /* сервер закрыл соединение */

13   printf("read %d bytes of home page\n", n);

14   /* обрабатываем полученные данные */

15  }

16  printf("end-of-file on home page\n");

17  Close(fd);

18 }

Установление соединения с сервером

7 Наша функция tcp_connect устанавливает соединение с сервером.

Отправка команды HTTP серверу, чтение ответа

8-17 Запускается команда HTTP GET для домашней страницы (часто обозначается символом /). Читается ответ (с ответом мы в данном случае ничего не делаем), и соединение закрывается.

Следующая функция, start_connect, показанная в листинге 16.11, инициирует вызов неблокируемой функции connect.

Листинг 16.11. Инициирование неблокируемой функции connect

//nonblock/start_connect.c

 1 #include "web.h"

 2 void

 3 start_connect(struct file *fptr)

 4 {

 5  int fd, flags, n;

 6  struct addrinfo *ai;

 7  ai = Host_serv(fptr->f_host, SERV, 0, SOCK_STREAM);

 8  fd = Socket(ai->ai_family; ai->ai_socktype, ai->ai_protocol);

 9  fptr->f_fd = fd;

10  printf("start_connect for %s, fd %d\n", fptr->f_name, fd);

11  /* отключаем блокирование сокета */

12  flags = Fcntl(fd, F_GETFL, 0);

13  Fcntl(fd, F_SETFL, flags | O_NONBLOCK);

14  /* инициируем неблокируемое соединение с сервером */

15  if ((n = connected, ai->ai_addr, ai->ai_addrlen)) < 0) {

16   if (errno != EINPROGRESS)

17    err_sys("nonblocking connect error");

18   fptr->f_flags = F_CONNECTING;

19   FD_SET(fd, &rset); /* включаем дескриптор сокета в наборе чтения

                           и записи */

20   FD_SET(fd, &wset);

21   if (fd > maxfd)

22    maxfd = fd;

23  } else if (n >= 0) /* соединение уже установлено */

24   write_get_cmd(fptr); /* отправляем команду GET серверу */

25 }

Создание сокета, отключение блокировки сокета

7-13 Мы вызываем нашу функцию host_serv для поиска и преобразования имени узла и имени службы. Она возвращает указатель на массив структур addrinfo. Мы используем только первую структуру. Создается сокет TCP, и он становится неблокируемым.

Вызов неблокируемой функции connect

14-22 Вызывается неблокируемая функция connect, и флагу файла присваивается значение F_CONNECTING. Включается дескриптор сокета и в наборе чтения, и в наборе записи, поскольку функция select будет ожидать любого из этих условий как указания на то, что установление соединения завершилось. При необходимости мы также обновляем значение maxfd.

Обработка завершения установления соединения

23-24 Если функция connect успешно завершается, значит, соединение уже установлено, и функция write_get_cmd (она показана в следующем листинге) посылает команду серверу.

Мы делаем сокет неблокируемым для функции connect, но никогда не переустанавливаем его в блокируемый режим, заданный по умолчанию. Это нормально, поскольку мы записываем в сокет только небольшое количество данных (команда GET следующей функции) и считаем, что эти данные занимают значительно меньше места, чем имеется в буфере отправки сокета. Даже если из-за установленного флага отсутствия блокировки при вызове функции write происходит частичное копирование, наша функция writen обрабатывает эту ситуацию. Если оставить сокет неблокируемым, это не повлияет на последующее выполнение функций read, потому что мы всегда вызываем функцию select для определения того момента, когда сокет станет готов для чтения.

В листинге 16.12 показана функция write_get_cmd, посылающая серверу команду HTTP GET.

Листинг 16.12. Отправка команды HTTP GET серверу

//nonblock/write_get_cmd.c

 1 #include "web.h"

 2 void

 3 write_get_cmd(struct file *fptr)

 4 {

 5  int n;

 6  char line[MAXLINE];

 7  n = snprintf(line, sizeof(line), GET_CMD, fptr->f_name);

 8  Writen(fptr->f_fd, line, n);

 9  printf("wrote %d bytes for %s\n", n, fptr->f_name);

10  fptr->f_flags = F_READING; /* сброс F_CONNECTING */

11  FD_SET(fptr->f_fd, &rset); /* прочитаем ответ сервера */

12  if (fptr->f_fd > maxfd)

13   maxfd = fptr->f_fd;

14 }

Создание команды и ее отправка

7-9 Команда создается и пишется в сокет.

Установка флагов

10-13 Устанавливается флаг F_READING, при этом также сбрасывается флаг F_CONNECTING (если он установлен). Это указывает основному циклу, что данный дескриптор готов для ввода. Также включается дескриптор в наборе чтения, и при необходимости обновляется значение maxfd.

Теперь мы возвращаемся в функцию main, показанную в листинге 16.13, начиная с того места, где закончили в листинге 16.9. Это основной цикл программы: пока имеется ненулевое количество файлов для обработки (значение nlefttoread больше нуля), устанавливается, если это возможно, другое соединение и затем вызывается функция select для всех активных дескрипторов, обрабатывающая как завершение неблокируемых соединений, так и прием данных.

Можем ли мы инициировать другое соединение?

24-35 Если мы не дошли до заданного предела одновременных соединений и есть дополнительные соединения, которые нужно установить, мы ищем еще не обработанный файл (на него указывает нулевое значение f_flags) и вызываем функцию start_connect для инициирования соединения. Число активных соединений увеличивается на единицу (nconn), а число соединений, которые нужно установить, на единицу уменьшается (nlefttoconn).

Функция select: ожидание событий

36-37 Функция select ожидает готовности сокета либо для чтения, либо для записи. Дескрипторы, для которых в настоящий момент происходит установление соединения (неблокируемая функция connect находится в процессе выполнения), будут включены в обоих наборах, в то время как дескрипторы с завершенным соединением, ожидающие данных от сервера, будут включены только в наборе чтения.

Листинг 16.13. Основной цикл функции main

//nonblock/web.c

24  while (nlefttoread > 0) {

25   while (nconn < maxnconn && nlefttoconn > 0) {

26    /* find a file to read */

27    for (i =0; i < nfiles; i++)

28     if (file[i].f_flags == 0)

29      break;

30    if (i == nfiles)

31     err_quit("nlefttoconn = %d but nothing found", nlefttoconn);

32    start_connect(&file[i]);

33    nconn++;

34    nlefttoconn--;

35   }

36   rs = rset:

37   ws = wset;

38   n = Select(maxfd + 1, &rs, &ws, NULL, NULL);

39   for (i = 0; i < nfiles; i++) {

40    flags = file[i].f_flags;

41    if (flags == 0 || flags & F_DONE)

42     continue;

43    fd = file[i].f_fd;

44    if (flags & F_CONNECTING &&

45     (FD_ISSET(fd, &rs) || FD_ISSET(fd, &ws))) {

46     n = sizeof(error);

47     if (getsockopt(fd, SOL_SOCKET, SO_ERROR, &error, &n) < 0 ||

48      error != 0) {

49      err_ret("nonblocking connect failed

50       for %s", file[i].f_name);

51     }

52     /* соединение установлено */

53     printf("connection established for %s\n", file[i].f_name);

54     FD_CLR(fd, &wset); /* отключаем запись в этот сокет */

55     write_get_cmd(&file[i]); /* передаем команду GET */

56    } else if (flags & F_READING && FD_ISSET(fd, &rs)) {

57     if ((n = Read(fd, buf, sizeof(buf))) == 0) {

58      printf("end-of-file on %s\n", file[i].f_name);

59      Close(fd);

60      file[i].f_flags = F_DONE; /* сбрасывает флаг F_READING */

61      FD_CLR(fd, &rset);

62      nconn--;

63      nlefttoread--;

64     } else {

65      printf("read %d bytes from %s\n", n, file[i].f_name);

66     }

67    }

68   }

69  }

70  exit(0);

71 }

Обработка всех готовых дескрипторов

39-55 Теперь мы анализируем каждый элемент массива структур file, чтобы определить, какие дескрипторы нужно обрабатывать. Если установлен флаг F_CONNECTING и дескриптор включен либо в наборе чтения, либо в наборе записи, неблокируемая функция connect завершается. Как мы говорили при описании листинга 16.7, мы вызываем функцию getsockopt, чтобы получить ожидающую обработки ошибку для сокета. Если значение ошибки равно нулю, соединение успешно завершилось. В этом случае мы выключаем дескриптор в наборе флагов записи и вызываем функцию write_get_cmd для отправки запроса HTTP серверу.

Проверка, есть ли у дескриптора данные

56-67 Если установлен флаг F_READING и дескриптор готов для чтения, мы вызываем функцию read. Если соединение было закрыто другим концом, мы закрываем сокет, устанавливаем флаг F_DONE, выключаем дескриптор в наборе чтения и уменьшаем число активных соединений и общее число соединений, требующих обработки.

Есть два способа оптимизации, которые мы не используем в этом примере (чтобы не усложнять его еще больше). Во-первых, мы можем завершить цикл for в листинге 16.13, когда мы обработали число дескрипторов, которые, по сообщению функции select, были готовы. Во-вторых, мы могли, где это возможно, уменьшить значение maxfd, чтобы функция select не проверяла биты дескрипторов, которые уже сброшены. Поскольку число дескрипторов, используемых в этом коде, в любой момент времени, вероятно, меньше 10, а не порядка тысяч, вряд ли какая-либо из этих оптимизаций стоит дополнительных усложнений.

Эффективность одновременных соединений

Каков выигрыш в эффективности при установлении множества одновременных соединений? В табл. 16.1 показано время, необходимое для выполнения определенной задачи, которая состоит в том, чтобы получить от веб-сервера домашнюю страницу и девять картинок. Время обращения RTT для данного соединения с сервером равно приблизительно 150 мс. Размер домашней страницы — 4017 байт, а средний размер девяти файлов с изображениями составил 1621 байт. Размер сегмента TCP равен 512 байт. Для сравнения мы также представляем в этой таблице значения для многопоточной версии данной программы, которую мы создаем в разделе 26.9.

Таблица 16.1. Время выполнения задания для разного количества одновременных соединений в разных версиях программы

ПРИМЕЧАНИЕ

Мы показали пример использования одновременных соединений, поскольку он служит хорошей иллюстрацией применения неблокируемого ввода-вывода, а также потому, что в данном случае эффективность применения одновременных соединений может быть измерена. Это свойство также используется в популярном приложении — веб-браузере Netscape. В этой технологии могут появиться некоторые «подводные камни», если сеть перегружена. В главе 21 [111] подробно описываются алгоритмы TCP, называемые алгоритмами медленного старта (slow start) и предотвращения перегрузки сети (congestion avoidance). Когда от клиента к серверу устанавливается множество соединений, то взаимодействие между соединениями на уровне TCP отсутствует. То есть если на одном из соединений происходит потеря пакета, другие соединения с тем же сервером не получают соответствующего уведомления, и вполне возможно, что другие соединения вскоре также столкнутся с потерей пакетов, пока не замедлятся. По этим дополнительным соединениям будет продолжаться отправка слишком большого количества пакетов в уже перегруженную сеть. Эта технология также увеличивает нагрузку на сервер.

Максимальное увеличение эффективности происходит при трех одновременных соединениях (время уменьшается вдвое), а при четырех и более одновременных соединениях прирост производительности значительно меньше.

Операции с кэшем ARP также осуществляются с помощью функции ioctl. В этих запросах используется структура arpreq, показанная в листинге 17.9 и определяемая в заголовочном файле .

Листинг 17.9. Структура arpreq, используемая с вызовами ioctl для кэша ARP

struct arpreq {

 struct sockaddr arp_pa;    /* адрес протокола */

 struct sockaddr arp_ha;    /* аппаратный адрес */

 int             arp_flags; /* флаги */

};

#define ATF_INUSE 0x01 /* запись, которую нужно использовать */

#define ATF_COM   0x02 /* завершенная запись */

#define ATF_PERM  0x04 /* постоянная запись */

#define ATF_PUBL  0x08 /* опубликованная запись (отсылается другим узлам) */

Третий аргумент функции ioctl должен указывать на одну из этих структур. Поддерживаются следующие три вызова:

■ SIOCSARP. Добавляет новую запись в кэш ARP или изменяет существующую запись. arp_pa — это структура адреса сокета Интернета, содержащая IP-адрес, a arp_ha — это общая структура адреса сокета с элементом ss_family, равным AF_UNSPEC, и элементом sa_data, содержащим аппаратный адрес (например, 6-байтовый адрес Ethernet). Два флага ATF_PERM и ATF_PUBL могут быть заданы приложением. Два других флага, ATF_INUSE и ATF_COM, устанавливаются ядром.

■ SIOCDARP. Удаляет запись из кэша ARP. Вызывающий процесс задает интернет-адрес удаляемой записи.

■ SIOCGARP. Получает запись из кэша ARP. Вызывающий процесс задает интернет-адрес, и соответствующий адрес Ethernet возвращается вместе с флагами.

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

ПРИМЕЧАНИЕ

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

Обратите внимание, что невозможно с помощью функции ioctl перечислить все записи кэша ARP. Большинство версий команды arp при использовании флага -a (перечисление всех записей кэша ARP) считывают память ядра (/dev/kmem), чтобы получить текущее содержимое кэша ARP. Мы увидим более простой (и предпочтительный) способ, основанный на применении функции sysctl, описанной в разделе 18.4.

Пример: вывод аппаратного адреса узла

Теперь мы используем нашу функцию my_addrs для того, чтобы возвратить все IP-адреса узла. Затем для каждого IP-адреса мы делаем вызов SIOCGARP функции ioctl, чтобы получить и вывести аппаратные адреса. Наша программа показана в листинге 17.10.

Листинг 17.10. Вывод аппаратного адреса узла

//ioctl/prmac.c

 1 #include "unpifi.h"

 2 #include

 3 int

 4 main(int argc, char **argv)

 5 {

 6  int sockfd;

 7  struct ifi_info *ifi;

 8  unsigned char *ptr;

 9  struct arpreq arpreq;

10  struct sockaddr_in *sin;

11  sockfd = Socket(AF_INET, SOCK_DGRAM, 0);

12  for (ifi = get_ifi_info(AF_INET, 0); ifi != NULL; ifi = ifi->ifi_next) {

13   printf("%s: ", Sock_ntop(ifi->ifi_addr, sizeof(struct sockaddr_in)));

14   sin = (struct sockaddr_in*)&arpreq.arp_pa;

15   memcpy(sin, ifi->ifi_addr, sizeof(struct sockaddr_in));

16   if (ioctl(sockfd, SIOCGARP, &arpreq) < 0) {

17    err_ret("ioctl SIOCGARP");

18    continue;

19   }

20   ptr = &arpreq.arp_ha.sa_data[0];

21   printf("%x:%x:%x:%x:%x:%x\n", *ptr, *(ptr+1),

22    *(ptr+2), *(ptr+3), *(ptr+4), *(ptr+5));

23  }

24  exit(0);

25 }

Получение списка адресов и проход в цикле по каждому из них

12 Мы вызываем функцию get_ifi_info, чтобы получить IP-адреса узла, а затем выполняем цикл по всем адресам.

Вывод IP-адреса

13 Мы выводим IP-адреса, используя функцию inet_ntop. Мы просим функцию get_ifi_info возвращать только адреса IPv4, так как ARP с IPv6 не используется.

Вызов функции ioctl и проверка ошибок

14-19 Мы заполняем структуру arp_pa как структуру адреса сокета IPv4, содержащую адрес IPv4. Вызывается функция ioctl, и если она возвращает ошибку (например, указанный адрес относится к интерфейсу, не поддерживающему ARP), мы выводим сообщение и переходим к следующему адресу.

Вывод аппаратного адреса

20-22 Выводится аппаратный адрес, возвращаемый ioctl.

При запуске этой программы на нашем узле hpux мы получаем:

hpux % prmac

192.6.38.100: 0:60:b0:c2:68:9b

192.168.1.1: 0:60:b0:b2:28:2b

127.0.0.1: ioctl SIOCGARP: Invalid argument

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

Таблица 18.1. Типы сообщений, проходящих по маршрутизирующему сокету

На маршрутизирующем сокете происходит обмен пятью различными структурами, как показано в последнем столбце таблицы: rt_msghdr, if_msghdr, if_announcemsghdr, ifma_msghdr и ifa_msghdr. Эти структуры представлены в листинге 18.2.

Листинг 18.2. Пять структур, возвращаемых с маршрутизирующими сообщениями

struct rt_msghdr { /* из */

 u_short rtm_msglen;  /* для пропуска некорректных сообщений */

 u_char  rtm_version; /* для обеспечения двоичной совместимости в будущем */

 u_char  rtm_type;    /* тип сообщения */

 u_short rtm_index; /* индекс интерфейса, с которым связан адрес */

 int     rtm_flags; /* флаги */

 int     rtm_addrs; /* битовая маска, идентифицирующая sockaddr (структуру адреса

                       сокета) в msg */

 pid_t   rtm_pid;   /* идентификация отправителя */

 int     rtm_seq;   /* для идентификации действия отправителем */

 int     rtm_errno; /* причина неудачного выполнения */

 int     rtm_use;   /* из rtentry */

 u_long  rtm_inits; /* какую метрику мы инициализируем */

 struct rt_metrics rtm_rmx; /* сами метрики */

};

struct if_msghdr { /* из */

 u_short ifm_msglen;  /* для пропуска некорректных сообщений */

 u_char  ifm_version; /* для обеспечения двоичной совместимости в будущем */

 u_char  ifm_type;    /* тип сообщения */

 int     ifm_addrs;       /* как rtm_addrs */

 int     ifm_flags;       /* значение if_flags */

 u_short ifm_index;       /* индекс интерфейса, с которым связан адрес */

 struct if_data ifm_data; /* статистические и другие сведения */

};

struct ifa_msghdr { /* из */

 u_short ifam_msglen;  /* для пропуска некорректных сообщений */

 u_char  ifam_version; /* для обеспечения двоичной совместимости в будущем */

 u_char  ifam_type;    /* тип сообщения */

 int     ifam_addrs;  /* как rtm_addrs */

 int     ifam_flags;  /* значение ifa_flags */

 u_short ifam_index;  /* индекс интерфейса, с которым связан адрес */

 int     ifam_metric; /* значение ifa_metric */

};

struct ifma_msghdr { /* из */

 u_short ifmam_msglen;  /* для пропуска некорректных сообщений */

 u_char  ifmam_version; /* для обеспечения двоичной совместимости в будущем */

 u_char  ifmam_type;    /* тип сообщения */

 int     ifmam_addrs;   /* аналог rtm_addrs */

 int     ifmam_flags;   /* значение ifa_flags */

 u_short ifmam_index;   /* индекс связанного ifp */

};

struct if_announcemsghdr { /* из */

 u_short ifan_msglen;  /* для пропуска некорректных сообщений */

 u_char  ifan_version; /* для обеспечения двоичной совместимости в будущем */

 u_char  ifan_type;    /* тип сообщения */

 u_short ifan_index;   /* индекс связанного ifp */

 char    ifan_name[IFNAMSIZ]; /* название интерфейса, напр. "en0" */

 u_short ifan_what;    /* тип объявления */

};

Первые три элемента каждой структуры одни и те же: длина, версия и тип сообщения. Тип — это одна из констант из первого столбца табл. 18.1. Элемент длины xxx_msglen позволяет приложению пропускать типы сообщений, которые оно не распознает.

Элементы rtm_addrs, ifm_addrs и ifam_addrs являются битовыми масками, указывающими, какая из возможных восьми структур адреса сокета следует за сообщением. В табл. 18.2 показаны константы и значения для битовой маски, определяемые в заголовочном файле .

Таблица 18.2. Константы, используемые для ссылки на структуры адреса сокета в маршрутизирующих сообщениях

В том случае, когда имеется множество структур адреса сокета, они всегда располагаются в порядке, показанном в таблице.

Пример: получение и вывод записи из таблицы маршрутизации

Теперь мы покажем пример использования маршрутизирующих сокетов. Наша программа получает аргумент командной строки, состоящий из адреса IPv4 в точечно-десятичной записи, и отправляет ядру сообщение RTM_GET для получения этого адреса. Ядро ищет адрес в своей таблице маршрутизации IPv4 и возвращает сообщение RTM_GET с информацией о соответствующей записи из таблицы маршрутизации. Например, если мы выполним на нашем узле freebsd такой код

freebsd # getrt 206.168.112.219

dest: 0.0.0.0

gateway: 12.106.32.1

netmask: 0.0.0.0

мы увидим, что этот адрес получателя использует маршрут по умолчанию (который хранится в таблице маршрутизации с IP-адресом получателя 0.0.0.0 и маской 0.0.0.0). Маршрутизатор следующей ретрансляции — это интернет-шлюз нашей системы. Если мы выполним

freebsd # getrt 192.168.42.0

dest: 192.168.42.0

gateway: AF_LINK, index=2

netmask: 255.255.255.0

задав в качестве получателя главную сеть Ethernet, получателем будет сама сеть. Теперь шлюзом является исходящий интерфейс, возвращаемый в качестве структуры sockaddr_dl с индексом интерфейса 2.

Перед тем как представить исходный код, мы показываем на рис. 18.1, что именно мы пишем в маршрутизирующий сокет и что возвращает ядро.

Рис. 18.1. Обмен данными с ядром на маршрутизирующем сокете для команды RTM_GET

Мы создаем буфер, содержащий структуру rt_msghdr, за которой следует структура адреса сокета, содержащая адрес получателя, информацию о котором должно найти ядро. Тип сообщения (rtm_type) — RTM_GET, а битовая маска (rtm_addrs) — RTA_DST (вспомните табл. 18.2). Эти значения указывают, что структура адреса сокета, следующая за структурой rt_msghdr, — это структура, содержащая адрес получателя. Эта команда может использоваться с любым семейством протоколов (предоставляющим таблицу маршрутизации), поскольку семейство адресов, в которое входит искомый адрес, указано в структуре адреса сокета.

После отправки сообщения ядру мы с помощью функции read читаем ответ, формат которого показан на рис. 18.1 справа: структура rt_msghdr, за которой следует до четырех структур адреса сокета. Какая из четырех структур адреса сокета возвращается, зависит от записи в таблице маршрутизации. Мы сможем идентифицировать возвращаемую структуру адреса сокета по значению элемента rtm_addrs возвращаемой структуры rt_msghdr. Семейство каждой структуры адреса сокета указано в элементе ss_family, и как мы видели в наших предыдущих примерах, первый раз сообщение RST_GET содержало информацию о том, что адрес шлюза является структурой адреса сокета IPv4, а второй раз это была структура адреса сокета канального уровня.

В листинге 18.3 показана первая часть нашей программы.

Листинг 18.3. Первая часть программы, запускающая команду RTM_GET на маршрутизирующем сокете

//route/getrt.c

 1 #include "unproute.h"

 2 #define BUFLEN (sizeof(struct rt_msghdr) + 512)

 3 /* sizeof(struct sockaddr_in6) * 8 = 192 */

 4 #define SEQ 9999

 5 int

 6 main(int argc, char **argv)

 7 {

 8  int sockfd;

 9  char *buf;

10  pid_t pid;

11  ssize_t n;

12  struct rt_msghdr *rtm;

13  struct sockaddr *sa, *rti_info[RTAX_MAX];

14  struct sockaddr_in *sin;

15  if (argc != 2)

16   err_quit("usage: getrt ");

17  sockfd = Socket(AF_ROUTE, SOCK_RAW, 0); /* необходимы права

                                привилегированного пользователя */

18  buf = Calloc(1, BUFLEN); /* инициализируется нулем */

19  rtm = (struct rt_msghdr*)buf;

20  rtm->rtm_msglen = sizeof(struct rt_msghdr) + sizeof(struct sockaddr_in);

21  rtm->rtm_version = RTM_VERSION;

22  rtm->rtm_type = RTM_GET;

23  rtm->rtm_addrs = RTA_DST;

24  rtm->rtm_pid = pid = getpid();

25  rtm->rtm_seq = SEQ;

26  sin = (struct sockaddr_in*)(rtm + 1);

27  sin->sin_len = sizeof(struct sockaddr_in);

28  sin->sin_family = AF_INET;

29  Inet_pton(AF_INET, argv[1], &sin->sin_addr);

30  Write(sockfd, rtm, rtm->rtm_msglen);

31  do {

32   n = Read(sockfd, rtm, BUFLEN);

33  } while (rtm->rtm_type != RTM_GET || rtm->rtm_seq != SEQ ||

34   rtm->rtm_pid != pid);

1-3 Наш заголовочный файл unproute.h подключает некоторые необходимые файлы, а затем включает наш файл unp.h. Константа BUFLEN — это размер буфера, который мы размещаем в памяти для хранения нашего сообщения ядру вместе с ответом ядра. Нам необходимо место для одной структуры rt_msghdr и, возможно, восьми структур адреса сокета (максимальное число, которое может возвратиться через маршрутизирующий сокет). Поскольку структура адреса сокета IPv6 имеет размер 28 байт, то значения 512 нам более чем достаточно.

Создание маршрутизирующего сокета

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

Заполнение структуры rt_msghdr

18-25 Мы заполняем структуру rt_msghdr данными нашего запроса. В этой структуре хранится идентификатор процесса и порядковый номер, который мы выбираем. Мы сравним эти значения, когда будем искать правильный ответ.

Заполнение структуры адреса сокета адресом получателя

26-29 Следом за структурой rt_msghdr мы создаем структуру sockaddr_in, содержащую IPv4-адрес получателя, поиск которого будет проведен ядром в таблице маршрутизации. Все, что мы задаем — это длина адреса, семейство адреса и адрес.

Запись сообщения ядру (функция write) и чтение ответа (функция read)

30-34 Мы передаем сообщение ядру с помощью функции write, и с помощью функции read читаем ответ. Поскольку у других процессов могут быть открытые маршрутизирующие сокеты, а ядро передает копию всех маршрутизирующих сообщений всем маршрутизирующим сокетам, мы должны проверить тип сообщения, порядковый номер и идентификатор процесса, чтобы узнать, что полученное сообщение — это ожидаемое нами сообщение.

Вторая часть этой программы показана в листинге 18.4. Она обрабатывает ответ.

Листинг 18.4. Вторая часть программы, запускающая команду RTM_GET на маршрутизирующем сокете

//route/getrt.c

35  rtm = (struct rt_msghdr*)buf;

36  sa = (struct sockaddr*)(rtm + 1);

37  get_rtaddrs(rtm->rtm_addrs, sa, rti_info);

38  if ((sa = rti_infо[RTAX_DST]) != NULL)

39   printf("dest: %s\n", Sock_ntop_host(sa, sa->sa_len));

40  if ((sa = rti_infо[RTAX_GATEWAY]) != NULL)

41   printf("gateway: %s\n", Sock_ntop_host(sa, sa->sa_len));

42  if ((sa = rti_info[RTAX_NETMASK]) != NULL)

43   printf("netmask: %s\n", Sock_masktop(sa, sa->sa_len));

44  if ((sa = rti_info[RTAX_GENMASK]) != NULL)

45   printf("genmask: %s\n", Sock_masktop(sa, sa->sa_len));

46  exit(0);

47 }

34-35 Указатель rtm указывает на структуру rt_msghdr, а указатель sa — на первую следующую за ней структуру адреса сокета.

36 rtm_addrs — это битовая маска той из возможных восьми структур адреса сокета, которая следует за структурой rt_msghdr. Наша функция get_rtaddrs (она показана в следующем листинге), получив эту маску и указатель на первую структуру адреса сокета (sa), заполняет массив rti_info указателями на соответствующие структуры адреса сокета. В предположении, что ядро возвращает все четыре структуры адреса сокета, показанные на рис. 18.1, полученный в результате массив rti_info будет таким, как показано на рис. 18.2.

Рис. 18.2. Структура rti_info, заполненная с помощью нашей функции get_rtaddrs

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

37-44 Каждый из присутствующих четырех возможных адресов выводится. Мы вызываем нашу функцию sock_ntop_host для вывода адреса получателя и адреса шлюза, но для вывода двух масок подсети вызываем нашу функцию sock_masktop. Эту новую функцию мы покажем далее.

В листинге 18.5 показана наша функция get_rtaddrs, которую мы вызывали в листинге 18.4.

Листинг 18.5. Создание массива указателей на структуры адреса сокета в маршрутизирующем сообщении

//libroute/get_rtaddrs.c

 1 #include "unproute.h"

 2 /*

 3  * Округляем 'а' до следующего значения, кратного 'size'

 4  */

 5 #define ROUNDUP(a, size) (((a) & ((size)-1)) ? (1 + ((a) | ((size)-1))) : (a))

 6 /* Переходим к следующей структуре адреса сокета.

 7  * Если sa_len равно 0, это значит, что

 8  * размер выражен числом типа u_long).

 9  */

10 #define NEXT_SA(ap) ар = (SA*) \

11  ((caddr_t)ар + (ap->sa_len ? ROUNDUP(ap->sa_len, sizeof(u_long)) : \

12  sizeof(u_long)))

13 void

14 get_rtaddrs(int addrs, SA *sa, SA **rti_info)

15 {

16  int i;

17  for (i = 0; i < RTAX_MAX; i++) {

18   if (addrs & (1 << i)) {

19    rti_info[i] = sa;

20    NEXT_SA(sa);

21   } else

22    rti_info[1] = NULL;

23  }

24 }

Цикл по восьми возможным указателям

Значение RTAX_MAX — максимальное число структур адреса сокета, возвращаемых от ядра в сообщении через маршрутизирующий сокет — равно 8. В цикле функции ведется поиск по каждой из восьми констант битовой маски RTA_xxx (см. табл. 18.2), которые могут быть присвоены элементам rtm_addrs, ifm_addrs и ifam_addrs структур, показанных в листинге 18.2. Если бит установлен, соответствующий элемент в массиве rti_info становится указателем на структуру адреса сокета; иначе элемент массива становится пустым указателем.

Переход к следующей структуре адреса сокета

2-12 Структуры адреса сокета имеют переменную длину, но в этом коде считается, что у каждой из них имеется поле sa_len, задающее длину структуры. Есть две сложности, с которыми придется столкнуться. Во-первых, маска подсети и маска клонирования могут возвращаться в структуре адреса сокета с нулевым значением поля sa_len, но на самом деле они занимают размер, представленный числом типа unsigned long (В главе 19 [128] обсуждается свойство клонирования таблицы маршрутизации 4.4BSD.) Это значение соответствует маске, состоящей только из нулевых битов, что мы видели в одном из приведенных выше примеров, когда для заданного по умолчанию маршрута маска подсети имела вид 0.0.0.0. Во-вторых, каждая структура адреса сокета может быть заполнена в конце таким образом, что следующая начнется на определенной границе, которая в данном случае соответствует значению типа unsigned long (например, 4-байтовая граница для 32-разрядной архитектуры). Хотя структуры sockaddr_in занимают 16 байт и не требуют заполнения, маски часто имеют в конце заполнение.

Последняя функция, которую мы покажем в примере нашей программы, — это функция sock_masktop, представленная в листинге 18.6, возвращающая строку для одного из двух возможных значений масок. Маски хранятся в структурах адреса сокета. Элемент sa_family не задан, но имеется элемент sa_len, принимающий значения 0, 5, 6, 7 или 8 для 32-битовых масок IPv4. Когда длина больше нуля, действительная маска начинается с того же смещения от начала структуры, что и адрес IPv4 в структуре sockaddr_in: 4 байта от начала структуры (как показано на рис. 18.21 [128]), что соответствует элементу sa_data[2] общей структуры адреса сокета.

Листинг 18.6. Преобразование значения маски к формату представления

//libroute/sock_masktop.c

 1 #include "unproute.h"

 2 const char*

 3 sock_masktop(SA *sa, socklen_t salen)

 4 {

 5  static char str[INET6_ADDRSTRLEN];

 6  unsigned char *ptr = &sa->sa_data[2];

 7  if (sa->sa_len == 0)

 8   return ("0.0.0.0");

 9  else if (sa->sa_len == 5)

10   snprintf(str, sizeof(str), '"%d.0.0.0", *ptr);

11  else if (sa->sa_len == 6)

12   snprintf(str, sizeof(str), "%d.%d.0.0", *ptr, *(ptr + 1));

13  else if (sa->sa_len == 7)

14   snprintf(str, sizeof(str), "%d.%d.%d.0", *ptr, *(ptr + 1), *(ptr + 2));

15  else if (sa->sa_len == 8)

16   snprintf(str, sizeof(str), "%d.%d.%d.%d",

17    *ptr, *(ptr + 1), *(ptr + 2), *(ptr + 3));

18  else

19  snprintf(str, sizeof(str), "(unknown mask, len = %d, family = %d)",

20   sa->sa_len, sa->sa_family);

21  return (str);

22 }

7-21 Если длина равна нулю, то подразумевается маска 0.0.0.0. Если длина равна 5, хранится только первый байт 32-разрядной маски, а для оставшихся трех байтов подразумевается нулевое значение. Когда длина равна 8, хранятся все 4 байта маски.

В этом примере мы хотим прочитать ответ ядра, поскольку он содержит информацию, которую мы ищем. Но в общем случае возвращаемое значение нашей функции write на маршрутизирующем сокете сообщает нам, успешно ли была выполнена команда. Если это вся необходимая нам информация, мы вызываем функцию shutdown со вторым аргументом SHUT_RD, чтобы предотвратить отправку ответа. Например, если мы удаляем маршрут, то возвращение нуля функцией write означает успешное выполнение, а если удалить маршрут не удалось, возвращается ошибка ESRCH [128, с. 608]. Аналогично, когда добавляется маршрут, возвращение ошибки EEXIST при выполнении функции write означает, что запись уже существует. В нашем примере из листинга 18.3 функция write возвращает ошибку ESRCH, если записи в таблице маршрутизации не существует (допустим, у нашего узла нет заданного по умолчанию маршрута).

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

#include

#include

int sysctl(int * name , u_int namelen , void * oldp , size_t * oldlenp ,

 void * newp , size_t Inewlen );

Возвращает: 0 в случае успешного выполнения

Эта функция использует имена, похожие на имена базы управляющей информации (Management Information Base, MIB) простого протокола управления сетью (Simple Network Management Protocol, SNMP). В главе 25 [111] подробно описываются SNMP и его MIB. Эти имена являются иерархическими.

Аргумент name — это массив целых чисел, задающий имя, a namelen задает число элементов массива. Первый элемент массива определяет, какой подсистеме ядра направлен запрос. Второй элемент определяет некую часть этой подсистемы, и т.д. На рис. 18.3 показана иерархическая организация с некоторыми константами, используемыми на первых трех уровнях.

Рис. 18.3. Иерархическая организация имен функции sysctl

Для получения значений используется аргумент oldp. Он указывает на буфер, в котором ядро сохраняет значение. Аргумент oldenp имеет тип «значение-результат»: когда функция вызывается, значение, на которое указывает oldenp, задает размер этого буфера, а по завершении функции значением этого аргумента становится количество данных, сохраненных ядром в буфере. Если размера буфера недостаточно, возвращается ошибка ENOMEM. В специальном случае oldp может быть пустым указателем, a oldenp — непустым указателем, и тогда ядро определяет, сколько данных возвратилось бы при вызове, сообщая это значение через oldenp.

Чтобы установить новое значение, используется аргумент newp, указывающий на буфер размера newlen. Если новое значение не задается, newp должен быть пустым указателем, a newlen должен быть равен нулю.

В руководстве (man) по применению функции sysctl подробно описывается различная системная информация, которую можно получить с помощью этой функции: информация о файловых системах, виртуальной памяти, ограничениях ядра, аппаратных характеристиках и т.д. Нас интересует сетевая подсистема, на которую указывает первый элемент массива name, равный CTL_NET (константы CTL_ xxx определяются в заголовочном файле ). Тогда второй элемент может быть одним из перечисленных ниже.

■ AF_INET. Получение или установка переменных, влияющих на протоколы Интернета. Следующий уровень с помощью одной из констант IPROTO_ xxx задает протокол. BSD/OS 3.0 предоставляет на этом уровне около 30 переменных, управляющих такими свойствами, как генерация ядром переадресации ICMP, использование параметров TCP из RFC 1323, отправка контрольных сумм UDP и т.д. Пример подобного применения функции sysctl мы покажем в конце этого раздела.

■ AF_LINK. Получение или установка информации канального уровня, такой как число интерфейсов PPP.

■ AF_ROUTE. Возвращение информации либо о таблице маршрутизации, либо о списке интерфейсов. Мы вскоре опишем эту информацию.

■ AF_UNSPEC. Получение или установка некоторых переменных уровня сокета, таких как максимальный размер буфера отправки или приема сокета.

Когда вторым элементом массива name является AF_ROUTE, третий элемент (номер протокола) всегда нулевой (поскольку протоколы внутри семейства AF_ROUTE отличаются от протоколов, например, в семействе AF_INET), четвертый элемент — это семейство адресов, а пятый и шестой элементы задают выполняемые действия. Вся эта информация обобщается в табл. 18.3.

Таблица 18.3. Информация функции sysctl, возвращаемая для маршрутизирующего домена

Поддерживаются три операции, задаваемые элементом name[4]. (Константы NET_RT_ xxx определяются в заголовочном файле .) Информация возвращается через указатель oldp при вызове функции sysctl. Этот буфер содержит переменное число сообщений RTM_ xxx (см. табл. 18.1).

1. Операция NET_RT_DUMP возвращает таблицу маршрутизации для семейства адресов, заданного элементом name[3]. Если задано нулевое семейство адресов, возвращаются таблицы маршрутизации для всех семейств адресов.

Рис. 18.4. Информация возвращаемая функцией sysctl для команд CTL_NET и NET_RT_IFLIST

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

2. Операция NET_RT_FLAGS возвращает таблицу маршрутизации для семейства адресов, заданного элементом name[3], но учитываются только те записи таблицы маршрутизации, для которых значение флага RTF_ xxx равно указанному в элементе name[5]. У всех записей кэша ARP в таблице маршрутизации установлен бит флага RTF_LLINFO.

Информация возвращается в том же формате, что и в предыдущем пункте.

3. Операция NET_RT_IFLIST возвращает информацию обо всех сконфигурированных интерфейсах. Если элемент name[5] ненулевой, это номер индекса интерфейса и возвращается информация только об этом интерфейсе. (Более подробно об индексах интерфейсов мы поговорим в разделе 18.6.) Все адреса, присвоенные каждому интерфейсу, также возвращаются, и если элемент name[3] ненулевой, возвращаются только адреса для семейства адресов, указанного в этом элементе.

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

Пример: определяем, включены ли контрольные суммы UDP

Теперь мы приведем простой пример использования функции sysctl с протоколами Интернета для проверки, включены ли контрольные суммы UDP. Некоторые приложения UDP (например, BIND) проверяют при запуске, включены ли контрольные суммы UDP, и если нет, пытаются включить их. Для того чтобы включить подобное свойство, требуются права привилегированного пользователя, но мы сейчас просто проверим, включено это свойство или нет. В листинге 18.7 представлена наша программа.

Листинг 18.7. Проверка включения контрольных сумм

//route/checkudpsum.c

 1 #include "unproute.h"

 2 #include

 3 #include

 4 #include /* для констант UDPCTL_xxx */

 5 int

 6 main(int argc, char **argv)

 7 {

 8  int mib[4], val;

 9  size_t len;

10  mib[0] = CTL_NET;

11  mib[1] = AF_INET;

12  mib[2] = IPPROTO_UDP;

13  mib[3] = UDPCTL_CHECKSUM;

14  len = sizeof(val);

15  Sysctl(mib, 4, &val, &len, NULL, 0);

16  printf("udp checksum flag: %d\n", val);

17  exit(0);

18 }

Включение системных заголовков

2-4 Следует включить заголовочный файл , чтобы получить определение констант UDP функции sysctl. Для него требуются два других заголовка.

Вызов функции sysctl

10-16 Мы размещаем в памяти массив целых чисел с четырьмя элементами и храним константы, соответствующие иерархии, показанной на рис. 18.3. Поскольку мы только получаем переменную и не присваиваем ей значение, аргумент newp функции sysctl мы задаем как пустой указатель, и поэтому аргумент newp этой функции имеет нулевое значение, oldp указывает на нашу целочисленную переменную, в которую сохраняется результат, a oldenp указывает на переменную типа «значение- результат», хранящую размер этого целого числа. Мы выводим либо 0 (отключено), либо 1 (включено).

Документ RFC 3493 [36] определяет четыре функции, обрабатывающие имена и индексы интерфейсов. Эти четыре функции используются во многих случаях, когда необходимо описать интерфейс. Они были предложены в процессе разработки API IPv6 (главы 21 и 27), однако индексы интерфейсов имеются и в API IPv4 (например, в вызове IP_RECVIF или AF_LINK для маршрутизирующего сокета). Основной принцип, объявляемый в этом документе, состоит в том, что каждый интерфейс имеет уникальное имя и уникальный положительный индекс (нуль в качестве индекса никогда не используется).

#include

unsigned int if_nametoindex(const char * ifname );

Возвращает: положительный индекс интерфейса в случае успешного выполнения, 0 в случае ошибки

char *if_indextoname(unsigned int ifindex , char * ifname );

Возвращает: указатель на имя интерфейса в случае успешного выполнения, NULL в случае ошибки

struct if_nameindex *if_nameindex(void);

Возвращает: непустой указатель в случае успешного выполнения, NULL в случае ошибки

void if_freenameindex(struct if_nameindex * Iptr );

Функция if_nametoindex возвращает индекс интерфейса, имеющего имя ifname. Функция if_indextoname возвращает указатель на имя интерфейса, если задан его индекс ifindex. Аргумент ifname указывает на буфер размера IFNAMSIZ (определяемый в заголовочном файле из листинга 17.1), который вызывающий процесс должен выделить для хранения результата, и этот указатель возвращается в случае успешного выполнения функции if_indextoname.

Функция if_nameindex возвращает указатель на массив структур if_nameindex:

struct if_nameindex {

 unsigned int if_index; /* 1, 2. ... */

 char *if_name; /* имя, завершаемое нулем: "le0", ... */

};

Последняя запись в этом массиве содержит структуру с нулевым индексом if_index и с пустым указателем ifname. Память для этого массива, а также для имен, на которые указывают элементы массива, выделяется динамически и освобождается при вызове функции if_freenameindex.

Теперь мы представим реализацию этих четырех функций с использованием маршрутизирующих сокетов.

Функция if_nametoindex

В листинге 18.11 показана функция if_nametoindex.

Листинг 18.11. Возвращение индекса интерфейса по его имени

//libroute/if_nametoindex.c

 1 #include "unpifi.h"

 2 #include "unproute.h"

 3 unsigned int

 4 if_nametoindex(const char *name)

 5 {

 6  unsigned int idx, namelen;

 7  char *buf, *next, *lim;

 8  size_t len;

 9  struct if_msghdr *ifm;

10  struct sockadd *sa, *rti_info[RTAX_MAX];

11  struct sockaddr_dl *sdl;

12  if ((buf = net_rt_iflist(0, 0, &len)) == NULL)

13   return(0);

14  namelen = strlen(name);

15  lim = buf + len;

16  for (next = buf; next < lim; next += ifm->ifm_msglen) {

17   ifm = (struct if_msghdr*)next;

18   if (ifm->ifm_type == RTM_IFINFO) {

19    sa = (struct sockaddr*)(ifm + 1);

20    get_rtaddrs(ifm->ifm_addrs, sa, rti_info);

21    if ((sa = rti_infо[RTAX_IFP]) != NULL) {

22     if (sa->sa_family == AF_LINK) {

23      sdl = (struct sockaddr_dl*)sa;

24      if (sdl->sdl_nlen == namelen

25       && strncmp(&sdl->sdl_data[0], name,

26       sdl->sdl_nlen) == 0) {

27       idx = sdl->sdl_index; /* сохранение перед

                                  вызовом free */

28       free(buf);

29       return(idx);

30      }

31     }

32    }

33   }

34  }

35  free(buf);

36  return(0); /* индекс для имени не найден */

37 }

Получение списка интерфейсов

12-13 Наша функция net_rt_iflist возвращает список интерфейсов.

Обработка только сообщений RTM_IFINFO

17-30 Мы обрабатываем сообщения в буфере (см. рис. 18.4) в поисках сообщений типа RTM_IFINFO. Найдя такое сообщение, мы вызываем нашу функцию get_rtaddrs, чтобы установить указатели на структуры адреса сокета, а если присутствует структура имени интерфейса (элемент RTAX_IFP массива rti_info), то имя интерфейса сравнивается с аргументом.

Функция if_indextoname

Следующая функция, if_indextoname, показана в листинге 18.12.

Листинг 18.12. Возвращение имени интерфейса по его индексу

libroute/if_indextoname.c

 1 #include "unpifi.h"

 2 #include "unproute.h"

 3 char*

 4 if_indextoname(unsigned int index, char *name)

 5 {

 6  char *buf, *next, *lim;

 7  size_t len;

 8  struct if_msghdr *ifm;

 9  struct sockaddr *sa, *rti_info[RTAX_MAX];

10  struct sockaddr_dl *sdl;

11  if ((buf = net_rt_iflist(0, index, &len)) == NULL)

12   return (NULL);

13  lim = buf + len;

14  for (next = buf; next < lim; next += ifm->ifm_msglen) {

15   ifm = (struct if_msghdr*)next;

16   if (ifm->ifm_type == RTM_IFINFO) {

17    sa = (struct sockaddr*)(ifm + 1);

18    get_rtaddrs(ifm->ifm_addrs, sa, rti_info);

19    if ((sa = rti_info[RTAX_IFP]) != NULL) {

20     if (sa->sa_family == AF_LINK) {

21      sdl = (struct sockaddr_dl*)sa;

22      if (sdl->sdl_index == index) {

23       int slen = min(IFNAMSIZ - 1, sdl->sdl_nlen);

24       strncpy(name, sdl->sdl_data, slen);

25       name[slen] = 0; /* завершающий нуль */

26       free(buf);

27       return (name);

28      }

29     }

30    }

31   }

32  }

33  free(buf);

34  return (NULL); /* нет соответствия индексу */

35 }

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

Функция if_nameindex

Следующая функция, if_nameindex, возвращает массив структур if_nameindex, содержащих все имена интерфейсов и индексы. Она показана в листинге 18.13.

Листинг 18.13. Возвращение всех имен и индексов интерфейсов

//libroute/if_nameindex.c

 1 #include "unpifi.h"

 2 #include "unproute.h"

 3 struct if_nameindex*

 4 if_nameindex(void)

 5 {

 6  char *buf, *next, *lim;

 7  size_t len;

 8  struct if_msghdr *ifm;

 9  struct sockaddr *sa, *rti_info[RTAX_MAX];

10  struct sockaddr_dl *sdl;

11  struct if_nameindex *result, *ifptr;

12  char *namptr;

13  if ((buf = net_it_iflist(0, 0, &len)) == NULL)

14   return (NULL);

15  if ((result = malloc(len)) == NULL) /* завышенная оценка */

16   return (NULL);

17  ifptr = result;

18  namptr = (char*)result + len; /* имена начинаются с конца буфера */

19  lim = buf + len;

20  for (next = buf; next < lim; next += ifm->ifm_msglen) {

21   ifm = (struct if_msghdr*)next;

22   if (ifm->ifm_type == RTM_IFINFO) {

23    sa = (struct sockaddr*)(ifm + 1);

24    get_rtaddrs(ifm->ifm_addrs, sa, rti_info);

25    if ((sa = rti_infо[RTAX_IFP]) != NULL) {

26     if (sa->sa_family == AF_LINK) {

27      sdl = (struct sockaddr_in*)sa;

28      namptr -= sdl->sdl_nlen + 1;

29      strncpy(namptr, &sdl->sdl_data[0], sdl->sdl_nlen);

30      namptr[sdl->sdl_nlen] = 0; /* завершающий нуль */

31      ifptr->if_name = namptr;

32      ifptr->if_index = sdl->sdl_index;

33      ifptr++;

34     }

35    }

36   }

37  }

38  ifptr->if_name = NULL; /* отмечаем конец массива структур */

39  ifptr->if_index = 0;

40  free(buf);

41  return (result); /* вызывающий процесс должен освободить память

                        с помощью free(), когда все сделано */

43 }

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

13-18 Мы вызываем нашу функцию net_rt_iflist для возвращения списка интерфейсов. Мы также используем возвращаемый размер в качестве размера буфера, который мы размещаем в памяти для записи массива возвращаемых структур if_nameindex. Оценка необходимого размера буфера несколько завышена, но это проще, чем проходить список интерфейсов дважды: один раз для подсчета числа интерфейсов и общего размера имен, а второй — для записи этой информации. Мы создаем массив if_nameindex в начале этого буфера и записываем имена интерфейсов, начиная с конца буфера.

Обработка только сообщений RTM_IFINFO

22-36 Мы обрабатываем все сообщения, ища сообщения RTM_IFINFO и следующие за ними структуры адреса сокета. Имя и индекс интерфейса записываются в создаваемый нами массив.

Завершение массива

38-39 Последняя запись в массиве имеет пустой указатель if_name и нулевой индекс.

Функция if_freenameindex

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

Листинг 18.14. Освобождение памяти, выделенной функцией if_nameindex

43 void

44 if_freenameindex(struct if_nameindex *ptr)

45 {

46  free(ptr);

47 }

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

Наиболее прямолинейным методом добавления соглашения о безопасности в базу является отправка сообщения SADB_ADD с заполненными параметрами, которые могут задаваться вручную. Последнее затрудняет смену ключей, которая необходима для предотвращения криптоаналитических атак, но зато упрощает настройку. Элис и Боб договариваются о ключах и алгоритмах без использования линий связи. Мы приводим последовательность действий по созданию и отправке сообщения SADB_ADD.

Сообщение SADB_ADD обязано иметь три расширения: соглашение о безопасности, адрес и ключ. Оно может дополняться и другими расширениями: временем жизни, личными данными и параметром важности (sensitivity). Сначала мы опишем обязательные расширения.

Расширение SA описывается структурой sadb_sa, представленной в листинге 19.3.

Листинг 19.3. Расширение SA

struct sadb_sa {

 u_int16_t sadb_sa_len;     /* длина расширения / 8 */

 u_int16_t sadb_sa_exttype; /* SADB_EXT_SA */

 u_int32_t sadb_sa_spi;     /* индекс параметров безопасности (SPI) */

 u_int8_t  sadb_sa_replay;  /* размер окна защиты от повторов или нуль */

 u_int8_t  sadb_sa_state;   /* состояние SA. см. табл. 19.4 */

 u_int8_t  sadb_sa_auth;    /* алгоритм аутентификации, см. табл. 19.5 */

 u_int8_t  sadb_sa_encrypt; /* алгоритм шифрования, см. табл. 19.5 */

 u_int32_t sadb_sa_flags;   /* флаги */

};

Таблица 19.4. Использование расширений

Таблица 19.5. Алгоритмы аутентификации и шифрования

Поле sadb_sa_spi содержит индекс параметров безопасности (security parameters index, SPI). Это значение вместе с адресом получателя и используемым протоколом (например, IPSec АН) уникально идентифицирует соответствующее соглашение о безопасности. При получении пакета значение SPI используется для поиска соглашения, относящегося к пакету. При отправке пакета значение помещается в него для использования получателем. Никаких иных значений SPI не имеет, поэтому назначаться индекс может последовательно, в случайном порядке или с использованием метода, рекомендуемого собеседником. Поле sadb_sa_replay задает размер окна защиты от повторов. Поскольку статические соглашения о защите не дают возможности задействовать эту защиту, мы устанавливаем поле равным нулю. Значение поля sadb_sa_state меняется в зависимости от состояния динамически создаваемых соглашений о безопасности (см. табл. 19.4). Создаваемые вручную соглашения существуют исключительно в состоянии SADB_SASTATE_MATURE. С другими состояниями мы встретимся в разделе 19.5.

Поля sadb_sa_auth и sadb_sa_encrypt определяют алгоритмы аутентификации и шифрования для данного соглашения. Возможные значения этих полей перечислены в табл. 19.5. Единственное значение поля sadb_sa_flags определено в POSIX как константа SADB_SAFLAGS_PFS. Этот флаг требует совершенной безопасности пересылки (perfect forward security), которая состоит в том утверждении, что значение ключа не должно зависеть от предыдущих подключений или какого-либо главного ключа. Флаг используется при запросе ключей у приложения, заведующего ими, но не при создании статических соглашений.

Следующее обязательное расширение команды SADB_ADD должно содержать адреса отправителя и получателя, задаваемые константами SADB_EXT_ADDRESS_SRC и SADB_EXT_ADDRESS_DST. При необходимости может быть указан адрес прокси-сервера SADB_EXT_ADDRESS_PROXY. Подробнее об обработке адресов прокси-серверов вы можете прочесть в RFC 2367 [73]. Адреса задаются в структуре sadb_address, представленной в листинге 19.4. Поле sadb_address_exttype определяет тип адреса (отправителя, получателя или прокси-сервера). Поле sadb_address_proto позволяет выбрать протокол IP или произвольный протокол (значение 0). Поле sadb_address_prefixlen описывает значимый префикс адреса. Это позволяет использовать одно соглашение для множества адресов. За структурой sadb_address следует структура sockaddr соответствующего семейства (например, sockaddr_in или sockaddr_in6). Номер порта из структуры sockaddr используется только в том случае, если поле sadb_address_proto задает протокол, поддерживающий номера портов (например, IPPROTO_TCP).

Листинг 19.4. Структура sadb_address

struct sadb_address {

 u_int16_t sadb_address_len;       /* длина расширения с адресом / 8 */

 u_int16_t sadb_address_exttype;   /* SADB_EXT_ADDRESS_{SRC,DST,PROXY} */

 u_int8_t  sadb_address_proto;     /* протокол IP или 0 (любой) */

 u_int8_t  sadb_address_prefixlen; /* # значащих битов адреса */

 u_int16_t sadb_address_reserved;  /* зарезервирован для послед. использования */

};

/* далее следует структура sockaddr соответствующего семейства */

Завершают список обязательных расширений сообщения SADB_ADD ключи аутентификации и шифрования — расширения SADB_EXT_KEY_AUTH и SADB_EXT_KEY_ENCRYPT, описываемые структурой sadb_key (листинг 19.5). Поле sadb_key_exttype определяет тип ключа (ключ аутентификации или шифрования), поле sadb_key_bits задает длину ключа в битах, а сам ключ следует за структурой sadb_key.

Листинг 19.5. Структура sadb_key

struct sadb_key {

 u_int16_t sadb_key_len;      /* длина расширения с ключом / 8 */

 u_int16_t sadb_key_exttype;  /* SADB_EXT_KEY_{AUTH,ENCRYPT} */

 u_int16_t sadb_key_bits;     /* # битов в ключе */

 u_int16_t sadb_key_reserved; /* зарезервировано для расширения */

};

/* далее следуют данные о самом ключе */

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

Листинг 19.6. Программа, использующая команду SADB_ADD

//key/add с

 33 void

 34 sadb_add(struct sockaddr *src, struct sockaddr *dst, int type, int alg,

 35  int spi, int keybits, unsigned char *keydata)

 36  {

 37  int s;

 38  char buf[4096], *p; /* XXX */

 39  struct sadb_msg *msg;

 40  struct sadb_sa *saext;

 41  struct sadb_address *addrext;

 42  struct sadb_key *keyext;

 43  int len;

 44  int mypid;

 45  s = Socket(PF_KEY, SOCK_RAW, PF_KEY_V2);

 46  mypid = getpid();

 47  /* Формирование и запись запроса SADB_ADD */

 48  bzero(&buf, sizeof(buf));

 49  p = buf;

 50  msg = (struct sadb_msg*)p;

 51  msg->sadb_msg_version = PF_KEY_V2;

 52  msg->sadb_msg_type = SADB_ADD;

 53  msg->sadb_msg_satype = type;

 54  msg->sadb_msg_pid = getpid();

 55  len = sizeof(*msg);

 56  p += sizeof(*msg);

 57  saext = (struct sadb_sa*)p;

 58  saext->sadb_sa_len = sizeof(*saext) / 8;

 59  saext->sadb_sa_exttype = SADB_EXT_SA;

 60  saext->sadb_sa_spi = htonl(spi);

 61  saext->sadb_sa_replay = 0; /* статические ключи не защищают от повтора */

 62  saext->sadb_sa_state = SADB_SASTATE_MATURE;

 63  saext->sadb_sa_auth = alg;

 64  saext->sadb_sa_encrypt = SADB_EALG_NONE;

 65  saext->sadb_sa_flags = 0;

 66  len += saext->sadb_sa_len * 8;

 67  p += saext->sadb_sa_len * 8;

 68  addrext = (struct sadb_address*)p;

 69  addrext->sadb_address_len = (sizeof(*addrext) + salen(src) + 7) / 8;

 70  addrext->sadb_address_exttype = SADB_EXT_ADDRESS_SRC;

 71  addrext->sadb_address_proto = 0; /* any protocol */

 72  addrext->sadb_address_prefixlen = prefix_all(src);

 73  addrext->sadb_address_reserved = 0;

 74  memcpy(addrext + 1, src, salen(src));

 75  len += addrext->sadb_address_len * 8,

 76  p += addrext->sadb_address_len * 8;

 77  addrext = (struct sadb_address*)p;

 78  addrext->sadb_address_len = (sizeof(*addrext) + salen(dst) + 7) / 8;

 79  addrext->sadb_address_exttype = SADB_EXT_ADDRESS_DST;

 80  addrext->sadb_address_proto = 0; /* any protocol */

 81  addrext->sadb_address_prefixlen = prefix_all(dst);

 82  addrext->sadb_address_reserved = 0;

 83  memcpy(addrext + 1, dst, salen(dst));

 84  len += addrext->sadb_address_len * 8;

 85  p += addrext->sadb_address_len * 8;

 86  keyext = (struct sadb_key*)p;

 87  /* обеспечивает выравнивание */

 88  keyext->sadb_key_len = (sizeof(*keyext) + (keybits / 8) + 7) / 8;

 89  keyext->sadb_key_exttype = SADB_EXT_KEY_AUTH;

 90  keyext->sadb_key_bits = keybits;

 91  keyext->sadb_key_reserved = 0;

 92  memcpy(keyext + 1, keydata, keybits / 8);

 93  len += keyext->sadb_key_len * 8;

 94  p += keyext->sadb_key_len * 8;

 95  msg->sadb_msg_len = len / 8;

 96  printf("Sending add message:\n");

 97  print_sadb_msg(buf, len);

 98  Write(s, buf, len);

 99  printf("\nReply returned:\n");

100  /* считывание и вывод ответа SADB_ADD, игнорируя любые другие */

101  for (;;) {

102   int msglen;

103   struct sadb_msg *msgp;

104   msglen = Read(s, &buf, sizeof(buf));

105   msgp = (struct sadb_msg*)&buf;

106   if (msgp->sadb_msg_pid == mypid &&

107    msgp->sadb_msg_type == SADB_ADD) {

108    print_sadb_msg(msgp, msglen);

109    break;

110   }

111  }

112  close(s);

113 }

Открытие сокета PF_KEY и сохранение PID

55-56 Как и в предыдущей программе, мы открываем сокет PF_KEY и сохраняем идентификатор нашего процесса для последующего его использования.

Формирование общего заголовка сообщений

47-56 Мы формируем заголовок сообщения SADB_ADD. Поле sadb_msg_len устанавливается непосредственно перед отправкой сообщения, поскольку оно должно соответствовать истинной его длине. В переменной len хранится текущая длина сообщения, а указатель р всегда указывает на первый неиспользуемый байт буфера.

Добавление расширения SA

57-67 Мы добавляем обязательное расширение SA (см. листинг 19.3). Поле sadb_sa_spi должно иметь сетевой порядок байтов, поэтому нам приходится применять функцию htonl к значению в порядке байтов узла. Мы отключаем защиту от повторов и устанавливаем состояние SA равным SADB_SASTATE_MATURE (см. табл. 19.4). Алгоритм аутентификации выбирается в соответствии с аргументом командной строки, а шифрование отключается при помощи константы SADB_EALG_NONE.

Добавление адреса отправителя

68-76 К сообщению добавляется расширение SADB_EXT_ADDRESS_SRC, содержащее адрес отправителя для соглашения о безопасности.

Значение протокола устанавливается равным нулю, что подразумевает действительность соглашения для всех протоколов. Длина префикса устанавливается равной соответствующей длине версии IP (то есть 32 разряда для IPv4 и 128 разрядов для IPv6). При расчете значения поля длины мы добавляем к реальному значению число 7 перед делением на 8, что гарантирует выравнивание по 64-разрядной границе, обязательное для всех расширений, передаваемых через сокеты PF_KEY. Структура sockaddr копируется в буфер после заголовка расширения.

Добавление адреса получателя

77-85 Адрес получателя добавляется в сообщение SADB_EXT_ADDRESS_DST. Процедура в точности совпадает с описанной выше.

Добавление ключа

86-94 К сообщению добавляется расширение SADB_EXT_KEY_AUTH, содержащее ключ авторизации. Расчет поля длины производится точно так же, как и для обоих адресов. Ключ переменной длины требует соответствующего количества дополняющих нулей. Мы устанавливаем значение количества битов и копируем ключ вслед за заголовком расширения.

Запись сообщения в сокет

95-98 Мы выводим сообщение на экран вызовом функции print_sadb_msg, после чего записываем его в сокет.

Считывание ответа

99-111 Мы считываем все сообщения из сокета до тех пор, пока не будет получено сообщение, адресованное нашему процессу (проверяется по PID) и имеющее тип SADB_ADD. Это сообщение выводится на экран функций print_sadb_msg, после чего программа завершает работу.

Пример

Мы запускаем программу, требуя от нее установки соглашения о безопасности, касающегося трафика между узлами 127.0.0.1 и 127.0.0.1 (то есть локального трафика):

macosx % add 127.0.0.1 127.0.0.1 HMAC-SHA-1-96 160 \

 0123456789abcdef0123456789abcdef01234567

Sending add message:

SADB Message Add, errno 0, satype IPsec AH, seq 0, pid 6246

SA: SPI=39030 Replay Window=0 State=Mature

Authentication Algorithm: HMAC-SHA-1

Encryption Algorithm: None

Source address: 127.0.0.1/32

Dest address: 127.0.0.1/32

Authentication key. 160 bits: 0x0123456789abcdef0123456789abcdef01234567

Reply returned:

SADB Message Add, errno 0, satype IPsec AH, seq 0, pid 6246

SA: SPI=39030 Replay Window=0 State=Mature

Authentication Algorithm: HMAC-SHA-1

Encryption Algorithm: None

Source address: 127.0.0.1/32

Dest address: 127.0.0.1/32

Обратите внимание, что в ответе системы отсутствует ключ. Дело в том; что ответ направляется на все сокеты PF_KEY, которые, однако, могут принадлежать к разным доменам, а данные о ключах не должны передаваться между доменами. После добавления записи в базу данных мы даем команду ping 127.0.0.1, чтобы проверить, задействуется ли соглашение о безопасности, после чего запрашиваем дамп базы данных и смотрим, что в ней изменилось.

macosx % dump

Sending dump message:

SADB Message Dump, errno 0, satype Unspecified, seq 0, pid 6283

Messages returned:

SADB Message Dump, errno 0, satype IPsec AH, seq 0, pid 6283

SA: SPI=39030 Replay Window=0 State=Mature

Authentication Algorithm: HMAC-SHA-1

Encryption Algorithm: None

[unknown extension 19]

Current lifetime:

36 allocations. 0 bytes

added at Thu Jun 5 21:01:31 2003, first used at Thu Jun 5 21:15:07 2003

Source address: 127.0.0.1/128 (IP proto 255)

Dest address: 127.0.0.1/128 (IP proto 255)

Authentication key. 160 bits: 0x0123456789abcdef0123456789abcdef01234567

Из этого дампа видно, что ядро изменило значение протокола с 0 на 255. Это артефакт реализации, а не общее свойство сокетов PF_KEY. Кроме того, ядро изменило длину префикса с 32 на 128. Это какая-то проблема, связанная с протоколами IPv4 и IPv6. Ядро возвращает расширение (с номером 19), которое не обрабатывается нашей программой выведения дампа. Неизвестные расширения пропускаются (их длина имеется в соответствующем поле). Наконец, возвращается расширение времени жизни (листинг 19.7), содержащее информацию о текущем времени жизни соглашения о безопасности.

Листинг 19.7. Структура расширения времени жизни

struct sadb_lifetime {

 u_int16_t sadb_lifetime_len;     /* длина расширения / 8 */

 u_int16_t sadb_lifetime_exttype; /* SADB_EXT_LIFETIME_{SOFT,HARD,CURRENT} */

 u_int32_t sadb_lifetime_allocations; /* количество соединений, конечных

                                       точек или потоков */

 u_int64_t sadb_lifetime_bytes;   /* количество байтов */

 u_int64_t sadb_lifetime_addtime; /* время создания либо время от создания

                                     до устаревания */

 u_int64_t sadb_lifetime_usetime; /* время первого использования или время от

                                     первого использования до устаревания */

};

Расширения времени жизни бывают трех типов. Расширения SADB_LIFETIME_SOFT и SADB_LIFETIME_HARD задают гибкое и жесткое ограничения на время жизни соглашения. Сообщение SADB_EXPIRE отправляется ядром в случае превышения гибкого ограничения на время жизни. После достижения жесткого ограничения использование соглашения прекращается. Расширение SADB_LIFETIME_CURRENT возвращается в ответ на SADB_DUMP, SADB_EXPIRE и SADB_GET и описывает соответствующие параметры текущего соглашения.

Для повышения безопасности требуется периодическая смена ключей. Обычно для этого используется протокол типа IKE (RFC 2409 [43]).

ПРИМЕЧАНИЕ

В момент написания этой книги рабочая группа IETF по IPSec разрабатывала замену для протокола IKE.

Демон, обеспечивающий безопасность, регистрируется в ядре при помощи сообщения SADB_REGISTER, указывая в поле sadb_msg_satype (см. табл. 19.2) тип соглашения о безопасности, которое он умеет обрабатывать. Если демон может работать с несколькими типами соглашений, он должен отправить несколько сообщений SADB_REGISTER, зарегистрировав в каждом из них ровно один тип SA. В ответном сообщении SADB_REGISTER ядро указывает поддерживаемые алгоритмы шифрования или аутентификации (в отдельном расширении), а также длины ключей для этих алгоритмов. Расширение поддерживаемых алгоритмов описывается структурой sadb_supported, представленной в листинге 19.8. Структура содержит заголовок, за которым следуют описания алгоритма шифрования или аутентификации в полях sadb_alg.

Листинг 19.8. Структура, описывающая поддерживаемые алгоритмы

struct sadb_supported {

 u_int16_t sadb_supported_len;      /* длина расширения и списка алгоритмов / 8 */

 u_int16_t sadb_supported_exttype;  /* SADB_EXT_SUPPORTED_{AUTH,ENCRYPT} */

 u_int32_t sadb_supported_reserved; /* зарезервировано для расширения в будущем */

};

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

struct sadb_alg {

 u_int8_t  sadb_alg_id;       /* идентификатор алгоритма из табл. 19.5 */

 u_int8_t  sadb_alg_ivlen;    /* длина IV или нуль */

 u_int16_t sadb_alg_minbits;  /* минимальная длина ключа */

 u_int16_t sadb_alg_maxbits;  /* максимальная длина ключа */

 u_int16_t sadb_alg_reserved; /* зарезервировано для расширения в будущем */

};

После заголовка sadb_supported следует по одной структуре sadb_alg для каждого алгоритма, поддерживаемого системой. На рис. 19.1 представлен возможный ответ на сообщение, регистрирующее обработчик SA типа SADB_SATYPE_ESP.

Рис. 19.1. Данные, возвращаемые ядром в ответ на команду SADB_REGISTER

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

Листинг 19.9. Регистрация демона-обработчика

//key/register.c

 1 void

 2 sadb_register(int type)

 3 {

 4  int s;

 5  char buf[4096]; /* XXX */

 6  struct sadb_msg msg;

 7  int goteof;

 8  int mypid;

 9  s = Socket(PF_KEY, SOCK_RAW, PF_KEY_V2);

10  mypid = getpid();

11  /* формирование и отправка запроса SADB_REGISTER */

12  bzero(&msg, sizeof(msg));

13  msg.sadb_msg_version = PF_KEY_V2;

14  msg.sadb_msg_type = SADB_REGISTER;

15  msg.sadb_msg_satype = type;

16  msg.sadb_msg_len = sizeof(msg) / 8;

17  msg.sadb_msg_pid = mypid;

18  printf("Sending register message:\n");

19  print_sadb_msg(&msg, sizeof(msg));

20  Write(s, &msg, sizeof(msg));

21  printf("\nReply returned:\n");

22  /* Чтение и вывод ответа SADB_REGISTER, игнорирование всех прочих

       сообщений */

23  for (;;) {

24   int msglen;

25   struct sadb_msg *msgp;

26   msglen = Read(s, &buf, sizeof(buf));

27   msgp = (struct sadb_msg*)&buf;

28   if (msgp->sadb_msg_pid == mypid &&

29    msgp->sadb_msg_type == SADB_REGISTER) {

30    print_sadb_msg(msgp, msglen);

31    break;

32   }

33  }

34  close(s);

35 }

Открытие сокета PF_KEY

1-9 Мы открываем сокет PF_KEY.

Сохранение PID

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

Создание сообщения SADB_REGISTER

11-17 Подобно SADB_DUMP, сообщение SADB_REGISTER не требует никаких расширений. Мы обнуляем сообщение, после чего заполняем интересующие нас поля структуры.

Вывод и отправка сообщения

18-20 Мы отображаем подготовленное сообщение на экране при помощи функции print_sadb_msg, после чего записываем сообщение в сокет.

Ожидание ответа

23-30 Мы считываем сообщения из сокета, ожидая ответа на наше сообщение о регистрации. Ответ адресован по идентификатору процесса и представляет собой сообщение SADB_REGISTER. Он содержит список поддерживаемых алгоритмов, который выводится нашей функцией print_sadb_msg.

Пример

Мы запускаем программу register в системе, поддерживающей на несколько протоколов больше, чем описано в RFC 2367.

macosx % register -t ah

Sending register message:

SADB Message Register, errno 0, satype IPsec AH, seq 0, pid 20746

Reply returned:

SADB Message Register, errno 0, satype IPsec AH, seq 0, pid 20746

Supported authentication algorithms:

HMAC-MD5 ivlen 0 bits 128-128

HMAC-SHA-1 ivlen 0 bits 160-160

Keyed MD5 ivlen 0 bits 128-128

Keyed SHA-1 ivlen 0 bits 160-160

Null ivlen 0 bits 0-2048

SHA2-256 ivlen 0 bits 256-256

SHA2-384 ivlen 0 bits 384-384

SHA2-512 ivlen 0 bits 512-512

Supported encryption algorithms:

DES-CBC ivlen 8 bits 64-64

3DES-CBC ivlen 8 bits 192-192

Null ivlen 0 bits 0-2048

Blowfish-CBC ivlen 8 bits 40-448

CAST128-CBC ivlen 8 bits 40-128

AES ivlen 16 bits 128-256

Если ядру требуется связаться с собеседником, а соответствующая политика требует наличия соглашения о безопасности, но соглашение таковое отсутствует, ядро отправляет на зарегистрировавшиеся для данного типа соглашения сокеты управления ключами сообщение SADB_ACQUIRE, в расширениях которого содержатся предлагаемые ядром алгоритмы и длины ключей. Предложение может представлять собой комбинацию поддерживаемых системой средств безопасности и политики, ограничивающей набор средств для конкретного собеседника. Алгоритмы, длины ключей и времена жизни объединяются в список в порядке предпочтительности использования. Когда демон-ключник получает сообщение SADB_ACQUIRE, он выполняет действия, необходимые для выбора ключа, удовлетворяющего одной из предложенных ядром комбинаций, и устанавливает этот ключ в ядро. Для выбора SPI из нужного диапазона демон отправляет ядру сообщение SADB_GETSPI. В ответ на это сообщение ядро создает соглашение о безопасности в состоянии SADB_SASTATE_LARVAL. Затем демон согласовывает параметры безопасности с удаленным собеседником, используя предоставленный ядром SPI, после чего отправляет ядру сообщение SADB_UPDATE для завершения создания соглашения и перевода его в рабочее состояние (SADB_SASTATE_MATURE). Динамически создаваемые соглашения обычно снабжаются гибким и жестким ограничениями на время жизни. Когда истекает один из этих сроков, ядро отправляет сообщение SADB_EXPIRE, в котором указывается, какое именно достигнуто ограничение. По достижении гибкого ограничения соглашение переходит в состояние SADB_SASTATE_DYING, в котором оно еще может использоваться, однако процессу следует получить новое соглашение. Если же достигнуто жесткое ограничение, соглашение переходит в состояние SADB_SASTATE_DEAD, в котором оно больше не может использоваться для обеспечения безопасности и должно быть удалено из базы данных.

Мы еще раз изменим нашу функцию dg_cli, на этот раз дав ей возможность отправлять широковещательные сообщения стандартному серверу времени и даты UDP (см. табл. 2.1) и выводить все ответы. Единственное изменение, внесенное нами в функцию main (см. листинг 8.3), состоит в изменении номера порта получателя на 13:

servaddr.sin_port = htons(13);

Сначала мы откомпилируем измененную функцию main с прежней функцией dg_cli из листинга 8.4 и запустим ее на узле freebsd:

freebsd % udpcli01 192.168.42.255

hi

sendto error: Permission denied

Аргумент командной строки — это широковещательный адрес подсети для присоединенной сети Ethernet. Мы вводим строку, программа вызывает функцию sendto, и возвращается ошибка EACCESS. Мы получаем ошибку, потому что нам не разрешается посылать дейтаграмму на широковещательный адрес получателя, если мы не указали ядру явно, что будем передавать широковещательное сообщение. Мы выполняем это условие, установив параметр сокета SO_BROADCAST (см. табл. 7.1).

ПРИМЕЧАНИЕ

Беркли-реализации реализуют эту «защиту от дурака» (sanity check). Однако Solaris 2.5 принимает дейтаграмму, предназначенную для широковещательного адреса, даже если мы не задаем параметр сокета SO_BROADCAST. Стандарт POSIX требует установки параметра сокета SO_BROADCAST для отправки широковещательной дейтаграммы.

В 4.2BSD широковещательная передача была привилегированной операцией, и параметра сокета SO_BROADCAST не существовало. В 4.3BSD этот параметр был добавлен и каждому процессу стало разрешено его устанавливать.

Теперь мы изменим нашу функцию dg_cli, как показано в листинге 20.1. Эта версия устанавливает параметр сокета SO_BROADCAST и выводит все ответы, полученные в течение 5 с.

Листинг 20.1. Функция dg_cli, осуществляющая широковещательную передачу

//bcast/dgclibcast1.c

 1 #include "unp.h"

 2 static void recvfrom_alarm(int);

 3 void

 4 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)

 5 {

 6  int n;

 7  const int on = 1;

 8  char sendline[MAXLINE], recvline[MAXLINE + 1];

 9  socklen_t len;

10  struct sockaddr *preply_addr;

11  preply_addr = Malloc(servlen);

12  Setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on));

13  Signal(SIGALRM, recvfrom_alarm);

14  while (Fgets(sendline, MAXLINE, fp) != NULL) {

15   Sendto(sockfd, sendline, strlen(sendline), 0, pservaddr, servlen);

16   alarm(5);

17   for (;;) {

18    len = servlen;

19    n = recvfrom(sockfd, recvline, MAXLINE, 0, preply_addr, &len);

20    if (n < 0) {

21     if (errno == EINTR)

22      break; /* окончание ожидания ответов */

23     else

24      err_sys("recvfrom error");

25    } else {

26     recvline[n] = 0; /* завершающий нуль */

27     printf("from %s: %s",

28      Sock_ntop_host(preply_addr, len), recvline);

29    }

30   }

31  }

32  free(preply_addr);

33 }

34 static void

35 recvfrom_alarm(int signo)

36 {

37  return; /* прерывание recvfrom() */

38 }

Выделение памяти для адреса сервера, установка параметра сокета

11-13 Функция malloc выделяет в памяти пространство для адреса сервера, возвращаемого функцией recvfrom. Устанавливается параметр сокета SO_BROADCAST, устанавливается обработчик сигнала SIGALRM.

Чтение строки, отправка сокету, чтение всех ответов

14-24 Следующие два вызова, fgets и sendto, выполняются так же, как и в предыдущих версиях этой функции. Но поскольку мы посылаем широковещательную дейтаграмму, мы можем получить множество ответов. Мы вызываем в цикле функцию recvfrom и выводим все ответы, полученные в течение 5 с. По истечении 5 с генерируется сигнал SIGALRM, вызывается наш обработчик сигнала и функция recvfrom возвращает ошибку EINTR.

Вывод каждого полученного ответа

25-29 Для каждого полученного ответа мы вызываем функцию sock_ntop_host, которая в случае IPv4 возвращает строку, содержащую IP-адрес сервера в точечно-десятичной записи. Эта строка выводится вместе с ответом сервера.

Если мы запустим программу, задав широковещательный адрес подсети 192. 168.42.255, мы увидим следующее:

bsdi % udpcli01 192.168.42.255 hi

from 192 168.42 2: Sat Aug 2 16.42.45 2003

from 192.168.42.1: Sat Aug 2 14.42.45 2003

from 192.168.42.3: Sat Aug 2 14.42.45 2003

hello

from 192.168.42.3: Sat Aug 2 14.42.57 2003

from 192.168.42.2: Sat Aug 2 16.42.57 2003

from 192.168.42.1: Sat Aug 2 14.42.57 2003

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

Все системы сообщают одно и то же время, поскольку на них используется NTP (Network Time Protocol — протокол синхронизации времени).

Фрагментация IP-пакетов и широковещательная передача

В Беркли-ядрах фрагментация широковещательных дейтаграмм запрещена. Если размер IP-дейтаграммы, посылаемой на широковещательный адрес, превышает размер MTU исходящего интерфейса, возвращается ошибка EMSGSIZE [128, с. 233–234]. Эта стратегия впервые появилась в 4.2BSD. На самом деле нет никаких технических препятствий для фрагментирования широковещательных дейтаграмм, но широковещательная передача сама по себе связана со значительной нагрузкой на сеть, поэтому не стоит дополнительно увеличивать эту нагрузку, используя фрагментацию.

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

bsdi % udpcli01 192.168.42.255 < 2000line

sendto error: Message too long

ПРИМЕЧАНИЕ

Это ограничение реализовано в AIX, FreeBSD и MacOS. Linux, Solaris и HP-UX фрагментируют дейтаграммы, отправленные на широковещательный адрес. Однако в целях переносимости приложение, которому нужно сделать широковещательный запрос, должно определять MTU для интерфейса, через который будет отправлено сообщение, при помощи параметра SIOCGIPMTU функции ioctl, после чего вычесть размер заголовков IP и транспортного протокола. Альтернативный подход: выбрать типичное значение MTU (например, 1500 для Ethernet) и использовать его в качестве константы.

Ситуация гонок (race condition) обычно возникает, когда множество процессов получают доступ к общим для них данным, но корректность результата зависит от порядка выполнения процессов. Поскольку порядок выполнения процессов в типичных системах Unix зависит от множества факторов, которые могут меняться от запуска к запуску, иногда результат корректен, а иногда — нет. Наиболее сложным для отладки типом гонок является такой, когда результат получается некорректным только изредка. Более подробно о ситуациях гонок мы поговорим в главе 26, когда будем обсуждать взаимные исключения (mutex) и условные переменные (condition variables). При программировании потоков всегда возникают проблемы с ситуациями гонок, поскольку значительное количество данных является общим для всех потоков (например, все глобальные переменные).

Ситуации гонок другого типа часто возникают при работе с сигналами. Проблемы возникают, потому что сигнал, как правило, может быть доставлен в любой момент во время выполнения нашей программы. POSIX позволяет нам блокировать доставку сигнала, но при выполнении операций ввода-вывода это часто не дает эффекта.

Чтобы понять эту проблему, рассмотрим пример. Ситуация гонок возникает при выполнении программы из листинга 20.1. Потратьте несколько минут и посмотрите, сможете ли вы ее обнаружить. (Подсказка: в каком месте программы мы можем находиться, когда доставляется сигнал?) Вы можете также инициировать ситуацию гонок следующим образом: изменить аргумент функции alarm с 5 на 1 и добавить вызов sleep(1) сразу же после printf.

Когда мы после внесения этих изменений наберем первую строку ввода, эта строка будет отправлена как широковещательное сообщение, а мы установим аргумент функции alarm равным 1 с. Мы блокируемся в вызове функции recvfrom, а затем для нашего сокета приходит первый ответ, вероятно, в течение нескольких миллисекунд. Ответ возвращается функцией recvfrom, но затем мы входим в спящее состояние на одну секунду. Принимаются остальные ответы и помещаются в приемный буфер сокета. Но пока мы находимся в спящем состоянии, время таймера alarm истекает и генерируется сигнал SIGALRM. При этом вызывается наш обработчик сигнала, затем он возвращает управление и прерывает функцию sleep, в которой мы блокированы. Далее мы повторяем цикл и читаем установленные в очередь ответы с паузой в одну секунду каждый раз, когда выводится ответ. Прочитав все ответы, мы снова блокируемся в вызове функции recvfrom, однако таймер уже не работает. Мы окажемся навсегда заблокированы в вызове функции recvfrom. Фундаментальная проблема здесь в том, что наша цель — обеспечить прерывание блокирования в функции recvfrom обработчиком сигнала, однако сигнал может быть доставлен в любое время, и наша программа в момент доставки сигнала может находиться в любом месте бесконечного цикла for.

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

Блокирование и разблокирование сигнала

Наше первое (некорректное) решение снижает вероятность появления ошибки, блокируя сигнал и предотвращая его доставку, пока наша программа выполняет оставшуюся часть цикла for. Эта версия представлена в листинге 20.2.

Листинг 20.2. Блокирование сигналов при выполнении в цикле for (некорректное решение)

//bcast/dgclibcast3.c

 1 #include "unp.h"

 2 static void recvfrom_alarm(int);

 3 void

 4 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)

 5 {

 6  int n;

 7  const int on = 1;

 8  char sendline[MAXLINE], recvline[MAXLINE + 1];

 9  sigset_t sigset_alrm;

10  socklen_t len;

11  struct sockaddr *preply_addr;

12  preply_addr = Malloc(servlen);

13  Setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on));

14  Sigemptyset(&sigset_alrm);

15  Sigaddset(&sigset_alrm, SIGALRM);

16  Signal(SIGALRM, recvfrom_alarm);

17  while (Fgets(sendline, MAXLINE, fp) != NULL) {

18   Sendto(sockfd, sendline, strlen(sendline), 0, pservaddr, servlen);

19   alarm(5);

20   for (;;) {

21    len = servlen;

22    Sigprocmask(SIG_UNBLOCK, &sigset_alrm, NULL);

23    n = recvfrom(sockfd, recvline, MAXLINE, 0, preply_addr, &len);

24    Sigprocmask(SIG_BLOCK, &sigset_alrm, NULL);

25    if (n < 0) {

26     if (errno == EINTR)

27      break; /* окончание ожидания ответа */

28     else

29      err_sys("recvfrom error");

30    } else {

31     recvline[n] = 0; /* завершающий нуль */

32     printf("from %s: %s",

33     Sock_ntop_host(preply_addr, len), recvline);

34    }

35   }

36  }

37  free(preply_addr);

38 }

39 static void

40 recvfrom_alarm(int signo)

41 {

42  return; /* выход из recvfrom() */

43 }

Объявление набора сигналов и инициализация

14-15 Мы объявляем набор сигналов, инициализируем его как пустой набор (sigemptyset) и включаем бит, соответствующий сигналу SIGALRM (sigaddset).

Разблокирование и блокирование сигнала

21-24 Перед вызовом функции recvfrom мы разблокируем сигнал (с тем, чтобы он мог быть доставлен, пока наша программа блокирована), а затем блокируем его, как только завершается функция recvfrom. Если сигнал генерируется (истекает время таймера), когда сигнал блокирован, то ядро запоминает этот факт, но доставить сигнал (то есть вызвать наш обработчик) не может, пока сигнал не будет разблокирован. В этом состоит принципиальная разница между генерацией сигнала и его доставкой. В главе 10 [110] предоставлена более подробная информация обо всех аспектах обработки сигналов POSIX.

Если мы откомпилируем и запустим эту программу, нам будет казаться, что она работает нормально, но все программы, порождающие ситуацию гонок, большую часть времени работают без каких-либо проблем! Проблема остается: разблокирование сигнала, вызов функции recvfrom и блокирование сигнала — все эти действия являются независимыми системными вызовами. Будем считать, что функция recvfrom возвращает последний ответ на нашу дейтаграмму, а сигнал доставляется между вызовом функции recvfrom и блокированием сигнала. Следующий вызов функции recvfrom заблокируется навсегда. Мы ограничили размер окна, но проблема осталась.

Вариантом решения может быть установка глобального флага при доставке сигнала его обработчиком:

recvfrom_alarm(int signo) {

 had_alarm = 1;

 return;

}

Флаг сбрасывается в 0 каждый раз, когда вызывается функция alarm. Наша функция dg_cli проверяет этот флаг перед вызовом функции recvfrom и не вызывает ее, если флаг ненулевой.

for (;;) {

 len = servlen;

 Sigprocmask(SIG_UNBLOCK, &sigset_alrm, NULL);

 if (had_alarm == 1)

  break;

 n = recvfrom(sockfd, recvline, MAXLINE, 0, preply_addr, &len);

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

Блокирование и разблокирование сигнала с помощью функции pselect

Одним из корректных решений будет использование функции pselect (см. раздел 6.9), как показано в листинге 20.3.

Листинг 20.3. Блокирование и разблокирование сигналов с помощью функции pselect

//bcast/dgclibcast4.с

 1 #include "unp.h"

 2 static void recvfrom_alarm(int);

 3 void

 4 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)

 5 {

 6  int n;

 7  const int on = 1;

 8  char sendline[MAXLINE], recvline[MAXLINE + 1];

 9  fd_set rset;

10  sigset_t sigset_alrm, sigset_empty;

11  socklen_t len;

12  struct sockaddr *preply_addr;

13  preply_addr = Malloc(servlen);

14  Setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on));

15  FD_ZERO(&rset);

16  Sigemptyset(&sigset_empty);

17  Sigemptyset(&sigset_alrm);

18  Sigaddset(&sigset_alrm, SIGALRM);

19  Signal(SIGALRM, recvfrom_alarm);

20  while (Fgets(sendline, MAXLINE, fp) != NULL) {

21   Sendto(sockfd, sendline, strlen(sendline), 0, pservaddr, servlen);

22   Sigprocmask(SIG_BLOCK, &sigset_alrm, NULL);

23   alarm(5);

24   for (;;) {

25    FD_SET(sockfd, &rset);

26    n = pselect(sockfd + 1, &rset, NULL, NULL, NULL, &sigset_empty);

27    if (n < 0) {

28     if (errno == EINTR)

29      break;

30     else

31      err_sys("pselect error");

32    } else if (n != 1)

33    err_sys("pselect error; returned %d", n);

34    len = servlen;

35    n = Recvfrom(sockfd, recvline, MAXLINE, 0, preply_addr, &len);

36    recvline[n] = 0; /* завершающий нуль */

37    printf("from %s: %s",

38    Sock_ntop_host(preply_addr, len), recvline);

39   }

40  }

41  free(preply_addr);

42 }

43 static void

44 recvfrom_alarm(int signo)

45 {

46  return; /* просто прерываем recvfrom() */

47 }

22-23 Мы блокируем сигнал SIGALRM и вызываем функцию pselect. Последний аргумент этой функции — указатель на нашу переменную sigset_empty, являющуюся набором сигналов, в котором нет блокированных сигналов (все сигналы разблокированы). Функция pselect сохранит текущую маску сигналов (которая блокирует SIGALRM), проверит заданные дескрипторы, заблокируется при необходимости с маской сигналов, установленной в пустой набор, но перед завершением функции маска сигналов процесса будет переустановлена в исходное значение, которое она имела при вызове функции pselect. Ключ к пониманию функции pselect в том, что установка маски сигналов, проверка дескрипторов и переустановка маски сигнала — это атомарные операции по отношению к вызывающему процессу.

34-38 Если наш сокет готов для чтения, мы вызываем функцию recvfrom, зная, что она не заблокируется.

Как мы упоминали в разделе 6.9, функция pselect — относительно новая среди других, описываемых спецификацией POSIX. Из всех систем, показанных на рис. 1.7, эту функцию поддерживают только FreeBSD и Linux. Тем не менее в листинге 20.4 представлена простая, хотя и некорректная ее реализация. Мы приводим ее здесь, несмотря на некорректность, чтобы продемонстрировать три стадии решения: установку маски сигнала в значение, заданное вызывающей функцией, с сохранением текущей маски, проверку дескрипторов и переустановку маски сигнала.

Листинг 20.4. Простая некорректная реализация функции pselect

//lib/pselect.c

 9 #include "unp.h"

10 int

11 pselect(int nfds, fd_set *rset, fd_set *wset, fd_set *xset,

12  const struct timespec *ts, const sigset_t *sigmask)

13  {

14  int n;

15  struct timeval tv;

16  sigset_t savemask;

17  if (ts != NULL) {

18   tv.tv_sec = ts->tv_sec;

19   tv.tv_usec = ts->tv_nsec / 1000; /* наносекунды -> микросекунды */

20  }

21  sigprocmask(SIG_SETMASK, sigmask, &savemask); /* маска вызывающего

                                                     процесса */

22  n = select(nfds, rset, wset, xset., (ts == NULL) ? NULL : &tv);

23  sigprocmask(SIG_SETMASK, &savemask, NULL); /* восстанавливаем

                                                  исходную маску */

24  return (n);

25 }

Использование функций sigsetjmp и siglongjmp

Нашу проблему можно решить корректно, если отказаться от прерывания блокированного системного вызова обработчиком сигнала, вместо этого вызвав из обработчика сигнала функцию siglongjmp. Этот метод называется нелокальным оператором goto (nonlocal goto), поскольку мы можем использовать его для перехода из одной функции в другую. В листинге 20.5 проиллюстрирована эта технология.

Листинг 20.5. Вызов функций sigsetjmp и siglongjmp из обработчика сигнала

//bcast/dgclibcast5.c

 1 #include "unp.h"

 2 #include

 3 static void recvfrom_alarm(int);

 4 static sigjmp_buf jmpbuf;

 5 void

 6 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)

 7 {

 8  int n;

 9  const int on = 1;

10  char sendline[MAXLINE], recvline[MAXLINE + 1];

11  socklen_t len;

12  struct sockaddr *preply_addr;

13  preply_addr = Malloc(servlen);

14  Setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on));

15  Signal(SIGALRM, recvfrom_alarm);

16  while (Fgets(sendline, MAXLINE, fp) != NULL) {

17   Sendto(sockfd, sendline, strlen(sendline), 0, pservaddr, servlen);

18   alarm(5);

19   for (;;) {

20    if (sigsetjmp(jmpbuf, 1) != 0)

21     break;

22    len = servlen;

23    n = Recvfrom(sockfd, recvline, MAXLINE, 0, preply_addr, &len);

24    recvline[n] = 0; /* null terminate */

25    printf("from %s: %s",

26     Sock_ntop_host(preply_addr, len), recvline);

27   }

28  }

29  free(preply_addr);

30 }

31 static void

32 recvfrom_alarm(int signo)

33 {

34  siglongjmp(jmpbuf, 1);

35 }

Размещение буфера перехода в памяти

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

Вызов функции sigsetjmp

20-23 Когда мы вызываем функцию sigsetjmp непосредственно из нашей функции dg_cli, она устанавливает буфер перехода и возвращает нуль. Мы продолжаем работать дальше и вызываем функцию recvfrom.

Обработка сигнала SIGALRM и вызов функции siglongjmp

31-35 Когда сигнал доставлен, мы вызываем функцию siglongjmp. Это заставляет sigsetjmp в функции dg_cli возвратить значение, равное второму аргументу (1), который должен быть ненулевым. Это приведет к завершению цикла for в функции dg_cli.

Использование функций sigsetjmp и siglongjmp подобным образом гарантирует, что мы не останемся навсегда блокированы в вызове функции recvfrom из-за доставки сигнала в неподходящее время. Однако такое решение создает иную потенциальную проблему. Если сигнал доставляется в тот момент, когда функция printf осуществляет вывод данных, управление будет передано из printf обратно на sigsetjmp. При этом в структурах данных printf могут возникнуть противоречия. Чтобы предотвратить эту проблему, следует объединить блокирование и разблокирование сигналов, показанное в листинге 20.2, с помощью нелокального оператора goto.

Применение IPC в обработчике сигнала функции

Существует еще один корректный путь решения нашей проблемы. Вместо того чтобы просто возвращать управление и, как мы надеемся, прерывать блокированную функцию recvfrom, наш обработчик сигнала при помощи средств IPC (Interprocess Communications — взаимодействие процессов) может сообщить функции dg_cli о том, что время таймера истекло. Это аналогично предложению, сделанному нами раньше, когда обработчик сигнала устанавливал глобальную переменную had_alarm по истечении времени таймера. Глобальная переменная использовалась как некая разновидность IPC (поскольку она была доступна и нашей функции, и обработчику сигнала). Однако при таком решении наша функция должна была проверять эту переменную, что могло привести к проблемам синхронизации в том случае, когда сигнал доставлялся приблизительно в это же время.

Листинг 20.6 демонстрирует использование канала внутри процесса. Обработчик сигналов записывает в канал 1 байт, когда истекает время таймера, а наша функция dg_cli считывает этот байт, чтобы определить, когда завершить свой цикл for. Что замечательно в этом решении — проверка готовности канала осуществляется функцией select. С ее помощью мы проверяем, готов ли к считыванию сокет или канал.

Листинг 20.6. Использование канала в качестве IPC между обработчиком сигнала и нашей функцией

//bcast/dgclibcast6.c

 1 #include "unp.h"

 2 static void recvfrom_alarm(int);

 3 static int pipefd[2];

 4 void

 5 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)

 6 {

 7  int n, maxfdp1;

 8  const int on = 1;

 9  char sendline[MAXLINE], recvline[MAXLINE + 1];

10  fd_set rset;

11  socklen_t len;

12  struct sockaddr *preply_addr;

13  preply_addr = Malloc(servlen);

14  Setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on));

15  Pipe(pipefd);

16  maxfdp1 = max(sockfd, pipefd[0]) + 1;

17  FD_ZERO(&rset);

18  Signal(SIGALRM, recvfrom_alarm);

19  while (Fgets(sendline, MAXLINE, fp) != NULL) {

20   Sendto(sockfd, sendline, strlen(sendline), 0, pservaddr, servlen);

21   alarm(5);

22   for (;;) {

23    FD_SET(sockfd, &rset);

24    FD_SET(pipefd[0], &rset);

25    if ((n = select(maxfdp1, &rset, NULL, NULL, NULL)) < 0) {

26     if (errno == EINTR)

27      continue;

28     else

29      err_sys("select error");

30    }

31    if (FD_ISSET(sockfd, &rset)) {

32     len = servlen;

33     n = Recvfrom(sockfd, recvline, MAXLINE, 0, preply_addr,

34      &len);

35     recvline[n] = 0; /* null terminate */

36     printf("from %s: %s",

37     Sock_ntop_host(preply_addr, len), recvline);

38    }

39    if (FD_ISSET(pipefd[0], &rset)) {

40     Read(pipefd[0], &n, 1); /* истекшее время */

41     break;

42    }

43   }

44  }

45  free(preply_addr);

46 }

47 static void

48 recvfrom_alarm(int signo)

49 {

50  Write(pipefd[1], "", 1); /* в канал пишется один нулевой байт */

51  return;

52 }

Создание канала

15 Мы создаем обычный канал Unix. Возвращаются два дескриптора: pipefd[0] доступен для чтения, а pipefd[0] — для записи.

ПРИМЕЧАНИЕ

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

Функция select на сокете и считывающем конце канала

23-30 Мы вызываем функцию select и на сокете, и на считывающем конце канала.

47-52 Когда доставляется сигнал SIGALRM, наш обработчик сигналов записывает в канал 1 байт, в результате чего считывающий конец канала становится готовым для чтения. Наш обработчик сигнала также возвращает управление, возможно, прерывая функцию select. Следовательно, если функция select возвращает ошибку EINTR, мы игнорируем эту ошибку, зная, что считывающий конец канала также готов для чтения, что завершит цикл for.

Чтение из канала

38-41 Когда считывающий конец канала готов для чтения, мы с помощью функции read считываем нулевой байт, записанный обработчиком сигнала, и игнорируем его. Но прибытие этого нулевого байта указывает нам на то, что истекло время таймера, и мы с помощью функции break выходим из бесконечного цикла for.

При описании адресов многоадресной передачи необходимо провести различия между IPv4 и IPv6.

Адреса IPv4 класса D

Адреса класса D, лежащие в диапазоне от 224.0.0.0 до 239.255.255.255, в IPv4 являются адресами многоадресной передачи (см. табл. А.1). Младшие 28 бит адреса класса D образуют идентификатор группы многоадресной передачи (multicast group ID), а 32-разрядный адрес называется адресом группы (group address).

На рис. 21.1 показано, как адреса многоадресной передачи сопоставляются адресам Ethernet. Сопоставление адресов групп IPv4 для сетей Ethernet описывается в RFC 1112 [26], для сетей FDDI — в RFC 1390 [59], а для сетей типа Token Ring — в RFC 1469 [97]. Чтобы обеспечить возможность сравнения полученных в результате адресов Ethernet, мы также показываем сопоставление для адресов групп Ipv6.

Рис. 21.1. Сопоставление адресам Ethernet адресов многоадресной передачи IPv4 и IPv6

Если рассматривать лишь сопоставление адресов IPv4, то в 24 старших битах адреса Ethernet всегда будет 01:00:5е. Следующий бит всегда нулевой, а 23 младших бита копируются из 23 младших битов группового адреса. Старшие 5 бит группового адреса при сопоставлении игнорируются. Это значит, что 32 групповых адреса сопоставляются одиночному адресу Ethernet, то есть соответствие не является взаимнооднозначным.

Младшие 2 бита первого байта адреса Ethernet идентифицируют адрес как универсально управляемый групповой адрес. «Универсально управляемый» означает то, что 24 старших бита были присвоены IEEE (Institute of Electrical and Electronics Engineers — Институт инженеров по электротехнике и электронике), а групповые адреса многоадресной передачи распознаются и обрабатываются получающими интерфейсами специальным образом.

Существует несколько специальных адресов многоадресной передачи IPv4:

■ 224.0.0.1 — это группа всех узлов (all-hosts group). Все узлы в подсети, имеющие возможность многоадресной передачи, должны присоединиться к этой группе интерфейсами, поддерживающими многоадресную передачу. (Мы поговорим о том, что значит присоединиться к группе, несколько позже.)

■ 224.0.0.2 — это группа всех маршрутизаторов (all-routers group). Все маршрутизаторы многоадресной передачи в подсети должны присоединиться к этой группе интерфейсами, поддерживающими многоадресную передачу.

Диапазон адресов от 224.0.0.0 до 224.0.0.255 (который мы можем также записать в виде 224.0.0.0/24), называется локальным на канальном уровне (link local). Эти адреса предназначены для низкоуровневого определения топологии и служебных протоколов, и дейтаграммы, предназначенные для любого из этих адресов, никогда не передаются маршрутизатором многоадресной передачи дальше. Более подробно об области действия различных групповых адресов IPv4 мы поговорим после того, как рассмотрим адреса многоадресной передачи IPv6.

Адреса многоадресной передачи IPv6

Старший байт адреса многоадресной передачи IPv6 имеет значение ff. На рис. 21.1 показано сопоставление 16-байтового адреса многоадресной передачи IPv6 6-байтовому адресу Ethernet. Младшие 32 бита группового адреса копируются в младшие 32 бита адреса Ethernet. Старшие 2 байта адреса Ethernet имеют значение 33:33. Это сопоставление для сетей Ethernet описано в RFC 2464 [23], то же сопоставление для FDDI — в RFC 2467 [24], а сопоставление для сетей типа Token Ring — в RFC 2470 [25].

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

Имеется два формата адресов многоадресной передачи IPv6 (рис. 21.2). Когда флаг P имеет значение 0, флаг T интерпретируется как обозначение принадлежности адреса к группе заранее известных (well-known — значение 0) или к группе временных (transient — значение 1). Если флаг P равен 1, адрес считается назначенным на основе одноадресного префикса (см. RFC 3306 [40]). При этом флаг T также должен иметь значение 1 (многоадресные адреса на основе одноадресных всегда являются временными), а поля plen и prefix устанавливаются равными длине и значению префикса соответственно. Верхние два бита этого поля зарезервированы. Адреса многоадресной передачи IPv6 имеют также 4-разрядное поле области действия (scope), которое будет описано ниже. Документ RFC 3307 [39] описывает механизм выделения младших 32 разрядов группового адреса IPv6 (идентификатора группы) в зависимости от значения флага P.

Рис. 21.2. Формат адресов многоадресной передачи IPv6

Существует несколько специальных адресов многоадресной передачи Ipv6:

■ ff02:1 — это группа всех узлов (all-nodes group). Все узлы подсети (компьютеры, маршрутизаторы, принтеры и т.д.), имеющие возможность многоадресной передачи, должны присоединиться к этой группе всеми своими интерфейсами, поддерживающими многоадресную передачу. Этот адрес аналогичен адресу многоадресной передачи IPv4 224.0.0.1. Однако поскольку многоадресная передача является неотъемлемой частью IPv6, присоединение к группе является обязательным (в отличие от IPv4).

ПРИМЕЧАНИЕ

Хотя группа IPv4 называется all-hosts, а группа IPv6 — all-nodes, назначение у них одно и то же. Группа IPv6 была переименована, чтобы подчеркнуть, что в нее должны входить маршрутизаторы, принтеры и любые другие IP-устройства подсети, а не только компьютеры (hosts).

■ ff02:2 — группа всех маршрутизаторов (all-routers group). Все маршрутизаторы многоадресной передачи в подсети должны присоединиться к этой группе интерфейсами, поддерживающими многоадресную передачу. Он аналогичен адресу многоадресной передачи IPv4 224.0.0.2.

Область действия адресов многоадресной передачи

Адреса многоадресной передачи IPv6 имеют собственное 4-разрядное поле области действия (scope), определяющее, насколько «далеко» будет передаваться пакет многоадресной передачи. Пакеты IPv6 вообще имеют поле предела количества транзитных узлов, которое ограничивает количество передач через маршрутизаторы (hop limit field). Поле области действия может принимать следующие значения:

■ 1: локальная в пределах узла (node-local);

■ 2: локальная в пределах физической сети (подсети) (link-local);

■ 4: локальная в пределах области администрирования (admin-local);

■ 5: локальная в пределах сайта (site-local);

■ 8: локальная в пределах организации (organization-local);

■ 14: глобальная (global).

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

В IPv4 нет отдельного поля области действия для многоадресных пакетов. Исторически поле TTL IPv4 в заголовке IP выполняло также роль поля области действия многоадресной передачи: TTL, равное нулю, означает адрес, локальный в пределах узла, 1 — локальный в пределах сети, значения до 32 — локальный в пределах сайта, до 64 — локальный в пределах региона, до 128 — локальный в пределах континента (это означает, что пакеты не передаются по низкоскоростным и загруженным каналам, даже если они проложены в пределах одного континента) и до 255 — неограниченная область действия (глобальный). Двойное использование поля TTL привело к ряду сложностей, подробно описанных в документе RFC 2365 [75].

Хотя использование поля TTL IPv4 для области действия является принятой и рекомендуемой практикой, предпочтительнее административное управление областями действия, если оно возможно. При этом диапазон адресов от 239.0.0.0 до 239.255.255.255 определяется как пространство многоадресной передачи IPv4 с административным ограничением области действия (administratively scoped IPv4 multicast space) [75]. Это верхняя граница пространства адресов многоадресной передачи. Адреса в этом диапазоне задаются организацией локально, но их уникальность за пределами организации не гарантируется. Организация должна настроить свои пограничные маршрутизаторы многоадресной передачи таким образом, чтобы пакеты многоадресной передачи, предназначенные для любого из этих адресов, не передавались вовне.

Административно управляемые адреса многоадресной передачи IPv4 затем делятся на локальную область действия и локальную в пределах организации область действия, первая из которых аналогична (но не является семантическим эквивалентом) области действия IPv6, локальной в пределах сайта. Различные правила определения области действия мы приводим в табл. 21.1.

Таблица 21.1. Область действия адресов многоадресной передачи IPv4 и IPv6

Сеансы многоадресной передачи

Сочетание адреса многоадресной передачи IPv4 или IPv6 и порта транспортного уровня часто называется сеансом (session), особенно если речь идет о передаче потокового мультимедиа. Например, телеконференция может объединять два сеанса: один аудио- и один видео-. Практически во всех случаях сеансы используют разные порты, а иногда и разные группы, что обеспечивает определенную гибкость для получателей. Например, один клиент может получать только аудиопоток, тогда как другой — аудио- и видео-. Если бы сеансы использовали один и тот же групповой адрес, это было бы невозможно.

Несмотря на то что параметры сокетов многоадресной передачи для IPv4 аналогичны параметрам сокетов многоадресной передачи для IPv6, есть достаточно много различий, из-за которых не зависящий от протокола код, использующий многоадресную передачу, усложняется и содержит множество директив #ifdef. Наилучшим решением будет использование приведенных ниже восьми функций, позволяющих скрыть различия реализаций:

#include "unp.h"

int mcast_join(int sockfd , const struct sockaddr * grp ,

 socklen_t grplen , const char * ifname , u_int ifindex );

int mcast_leave(int sockfd , const struct sockaddr * grp ,

 socklen_t grplen );

int mcast_block_source(int sockfd ,

 const struct sockaddr * src , socklen_t srclen ,

 const struct sockaddr * grp , socklen_t grplen );

int mcast_unblock_source(int sockfd ,

 const struct sockaddr * src , socklen_t srclen ,

 const struct sockaddr * grp , socklen_t grplen );

int mcast_join_source_group(int sockfd ,

 const struct sockaddr * src , socklen_t srclen ,

 const struct sockaddr * grp , socklen_t grplen ,

 const char * ifname , u_int ifindex );

int mcast_leave_source_group(int sockfd ,

 const struct sockaddr * src , socklen_t srclen ,

 const struct sockaddr * grp , socklen_t grplen );

int mcast_set_if(int sockfd , const char * ifname , u_int ifindex );

 int mcast_set_loop(int sockfd , int flag );

int mcast_set_ttl(int sockfd , int ttl );

Все перечисленные выше функции возвращают: 0 в случае успешного выполнения, -1 в случае ошибки

int mcast_get_if(int sockfd );

Возвращает: неотрицательный индекс интерфейса в случае успешного выполнения, -1 в случае ошибки

int mcast_get_loop(int sockfd );

Возвращает: текущий флаг закольцовки в случае успешного выполнения, -1 в случае ошибки

int mcast_get_ttl(int sockfd );

Возвращает: текущее значение TTL или предельное количество транзитных узлов в случае успешного выполнения, -1 в случае ошибки

Функция mcast_join присоединяет узел к группе. IP-адрес этой группы содержится в структуре адреса сокета, на которую указывает аргумент grp, а длина этой структуры задается аргументом grplen. Мы можем задать интерфейс, на котором должно происходить присоединение к группе, либо через имя интерфейса (непустой аргумент ifname), либо через ненулевой индекс интерфейса (непустой аргумент ifindex). Если ни одно из этих значений не задано, ядро самостоятельно выбирает интерфейс, на котором происходит присоединение к группе. Вспомните, что в случае IPv6 для работы с параметрами сокета интерфейс задается по его индексу. Если для сокета IPv6 известно имя интерфейса, нужно вызвать функцию if_nametoindex, чтобы получить индекс интерфейса. В случае параметра сокета IPv4 мы задаем интерфейс по его IP-адресу направленной передачи. Если для сокета IPv4 интерфейс задан по имени, нужно вызвать функцию ioctl с запросом SIOCGIFADDR для получения IP-адреса направленной передачи для этого интерфейса. Если для сокета IPv4 задан индекс интерфейса, мы сначала вызываем функцию if_indextoname, чтобы получить имя интерфейса, а затем обрабатываем имя так, как только что было сказано.

ПРИМЕЧАНИЕ

Пользователи обычно задают имя интерфейса le0 или ether0, а IP-адрес и индекс интерфейса не используются. Например, tcpdump является одной из немногих программ, позволяющих пользователю задавать интерфейс, а ее параметр -i принимает имя интерфейса в качестве аргумента.

Функция mcast_leave выводит узел из группы с IP-адресом, содержащимся в структуре адреса сокета, на которую указывает аргумент grp.

Функция mcast_block_source блокирует получение через конкретный сокет пакетов, относящихся к определенной группе и исходящих от определенного источника. IP-адреса группы и источника хранятся в структурах адреса сокета, на которые указывают аргументы grp и src соответственно. Длины структур задаются параметрами srclen и grplen. Для успешного завершения функции необходимо, чтобы до ее вызова уже была вызвана функция mcast_join для того же сокета и той же группы.

Функция mcast_unblock_source разблокирует получение трафика от источника из заданной группы. Аргументы src, srclen, grp и grplen имеют тот же смысл, что и аргументы предыдущей функции, и должны совпадать с ними по значениям.

Функция mcast_join_source_group выполняет присоединение к группе источника. Адрес источника и адрес группы содержатся в структурах адреса сокета, на которые указывают аргументы src и grp. Длины структур задаются параметрами srclen и grplen. Интерфейс, присоединяемый к группе, может быть задан именем (ненулевой аргумент ifname) или индексом (ifindex). Если интерфейс не задан явно, ядро выбирает его самостоятельно.

Функция mcast_leave_source_group выполняет отсоединение от группы источника. Адреса источника и группы содержатся в структурах адреса сокета, на которые указывают аргументы src и grp. Длины структур задаются параметрами srclen и grplen. Подобно mcast_leave, mcast_leave_source_group не требует указания интерфейса: она всегда отсоединяет от группы первый интерфейс, удовлетворяющий условиям.

Функция mcast_set_if устанавливает индекс интерфейса по умолчанию для исходящих дейтаграмм многоадресной передачи. Если аргумент ifname непустой, он задает имя интерфейса. Иначе положительное значение аргумента ifindex будет задавать индекс интерфейса. В случае IPv6 имя сопоставляется индексу с использованием функции if_nametoindex. В случае IPv4 сопоставление имени или индекса IP-адресу направленной передачи интерфейса происходит так же, как для функции mcast_join.

Функция mcast_set_loop устанавливает параметр закольцовки либо в 0, либо в 1, а функция mcast_set_ttl TTL в случае IPv4 или предел количества транзитных узлов в случае IPv6. Функции mcast_get_XXX возвращают соответствующие значения.

Пример: функция mcast_join

В листинге 21.1 показана первая часть функции mcast_join. Эта часть демонстрирует простоту интерфейса программирования, не зависящего от протокола.

Листинг 21.1. Присоединение к группе: сокет IPv4

//lib/mcast_join.c

 1 #include "unp.h"

 2 #include

 3 int

 4 mcast_join(int sockfd, const SA *grp, socklen_t grplen,

 5 const char *ifname, u_int ifindex)

 6 {

 7 #ifdef MCAST_JOIN_GROUP

 8  struct group_req req;

 9  if (ifindex > 0) {

10   req.gr_interface = ifindex;

11  } else if (ifname != NULL) {

12   if ((req.gr_interface = if_nametoindex(ifname)) == 0) {

13    errno = ENXIO; /* интерфейс не найден */

14    return(-1);

15   }

16  } else

17  req.gr_interface = 0;

18  if (grplen > sizeof(req.gr_group)) {

19   errno = EINVAL;

20   return -1;

21  }

22  memcpy(&req.gr_group, grp, grplen);

23  return (setsockopt(sockfd, family_to_level(grp->sa_family),

24  MCAST_JOIN_GROUP, &req, sizeof(req)));

25 #else

Обработка индекса

9-17 Если при вызове был указан индекс интерфейса, функция использует его непосредственно. В противном случае (при указании имени интерфейса), имя преобразуется в индекс вызовом if_nametoindex. Если ни имя, ни индекс не заданы, интерфейс выбирается ядром.

Копирование адреса и вызов setsockopt

18-22 Адрес сокета копируется непосредственно в поле группы. Вспомните, что поле это имеет тип sockaddr_storage, а потому достаточно велико для хранения адреса любого типа, поддерживаемого системой. Для предотвращения переполнения буфера (при ошибках в программе) мы проверяем размер sockaddr и возвращаем EINVAL, если он слишком велик.

23-24 Присоединение к группе выполняется вызовом setsockopt. Аргумент level определяется на основании семейства группового адреса вызовом нашей собственной функции family_to_level. Некоторые системы допускают несоответствие аргумента level семейству адреса сокета, например использование IPPROTO_IP с MCAST_JOIN_GROUP, даже если сокет относится к семейству AF_INET6, но это верно не для всех систем, поэтому мы и должны выполнить преобразование семейства к нужному значению level. Листинг этой тривиальной функции в книге мы не приводим, но исходный код этой функции вы можете скачать вместе со всеми остальными программами.

В листинге 21.2 представлена вторая часть функции mcast_join, обрабатывающая сокеты IPv4.

Листинг 21.2. Присоединение к группе: обработка сокета IPv4

26  switch (grp->sa_family) {

27  case AF_INET: {

28   struct ip_mreq mreq;

29   struct ifreq ifreq;

30   memcpy(&mreq.imr_multiaddr,

31    &((const struct sockaddr_in*)grp)->sin_addr,

32    sizeof(struct in_addr));

33    if (ifindex > 0) {

34     if (if_indextoname(ifindex, ifreq.ifr_name) == NULL) {

35      errno = ENXIO; /* i/f index not found */

36      return(-1);

37     }

38     goto doioctl;

39    } else if (ifname != NULL) {

40     strncpy(ifreq.ifr_name, ifname, IFNAMSIZ);

41 doioctl:

42     if (ioctl(sockfd, SIOCGIFADDR, &ifreq) < 0)

43      return(-1);

44     memcpy(&mreq.imr_interface,

45      &((struct sockaddr_in*)&ifreq.ifr_addr)->sin_addr,

46      sizeof(struct in_addr));

47    } else

48     mreq.imr_interface.s_addr = htonl(INADDR_ANY);

49    return(setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP,

50     &mreq, sizeof(mreq)));

51   }

Обработка индекса

33-38 Адрес многоадресной передачи IPv4 в структуре адреса сокета копируется в структуру ip_mreq. Если индекс был задан, вызывается функция if_indextoname, сохраняющая имя в нашей структуре ip_mreq. Если это выполняется успешно, мы переходим на точку вызова ioctl.

Обработка имени

39-46 Имя вызывающего процесса копируется в структуру ip_mreq, а вызов SIOCGIFADDR функции ioctl возвращает адрес многоадресной передачи, связанный с этим именем. При успешном выполнении адрес IPv4 копируется в элемент imr_interface структуры ip_mreq.

Значения по умолчанию

47-48 Если ни индекс, ни имя не заданы, используется универсальный адрес, что указывает ядру на необходимость выбрать интерфейс.

49-50 Функция setsockopt выполняет присоединение к группе.

Третья, и последняя, часть функции, обрабатывающая сокеты IPv6, приведена в листинге 21.3.

Листинг 21.3. Присоединение к группе: обработка сокета IPv6

52 #ifdef IPV6

53  case AF_INET6: {

54   struct ipv6_mreq mreq6;

55   memcpy(&mreq6.ipv6mr_multiaddr,

56    &((const struct sockaddr_in6*) grp)->sin6_addr,

57    sizeof(struct in6_addr));

58    if (ifindex > 0) {

59     mreq6.ipv6mr_interface = ifindex;

60    } else if (ifname != NULL) {

61     if ((mreq6.ipv6mr_interface = if_nametoindex(ifname)) == 0) {

62      errno = ENXIO; /* интерфейс не найден */

63      return(-1);

64     }

65    } else

66     mreq6.ipv6mr_interface = 0;

67    return(setsockopt(sockfd, IPPROTO_IPV6, IPV6_JOIN_GROUP,

68     &mreq6, sizeof(mreq6)));

69   }

70 #endif

71  default:

72   errno = EAFNOSUPPORT;

73   return(-1);

74  }

75 #endif

76 }

Копирование адреса

55-57 Сначала адрес IPv6 копируется из структуры адреса сокета в структуру ipv6_mreq.

Обработка индекса или имени интерфейса или выбор интерфейса по умолчанию

58-66 Если был задан индекс, он записывается в элемент ipv6mr_interface. Если индекс не задан, но задано имя, то для получения индекса вызывается функция if_nametoindex. В противном случае для функции setsockopt индекс устанавливается в 0, что указывает ядру на необходимость выбрать интерфейс.

67-68 Выполняется присоединение к группе.

Пример: функция mcast_set_loop

В листинге 21.4 показана наша функция mcast_set_loop.

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

Мы не показываем исходный код для всех остальных функций mcast_ XXX , так как он свободно доступен в Интернете (см. предисловие).

Листинг 21.4. Установка параметра закольцовки для многоадресной передачи

//lib/mcast_set_loop.c

 1 #include "unp.h"

 2 int

 3 mcast_set_loop(int sockfd, int onoff)

 4 {

 5  switch (sockfd_to_family(sockfd)) {

 6  case AF_INET:{

 7   u_char flag;

 8   flag = onoff;

 9   return (setsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_LOOP,

10    &flag, sizeof(flag)));

11  }

12 #ifdef IPV6

13  case AF_INET6:{

14   u_int flag;

15   flag = onoff;

16   return (setsockopt(sockfd, IPPROTO_IPV6, IPV6_MULTICAST_LOOP,

17    &flag, sizeof(flag)));

18  }

19 #endif

20  default:

21   errno = EPROTONOSUPPORT;

22   return (-1);

23  }

24 }

Мы изменяем нашу функцию dg_cli, показанную в листинге 20.1, просто удаляя вызов функции setsockopt. Как мы сказали ранее, для отправки дейтаграмм многоадресной передачи не нужно устанавливать ни одного параметра сокета многоадресной передачи, если нас устраивают заданные по умолчанию настройки интерфейса исходящих пакетов, значения TTL и параметра закольцовки. Мы запускаем нашу программу, задавая в качестве адреса получателя группу всех узлов (all-hosts group):

macosx % udpcli01 224.0.1.1

hi there

from 172.24.37.78: hi there MacOS X

from 172.24.37.94: hi there FreeBSD

Отвечают оба узла, находящиеся в подсети. На обоих работают многоадресные эхо-серверы. Каждый ответ является направленным, поскольку адрес отправителя запроса, используемый сервером в качестве адреса получателя ответа, является адресом направленной передачи.

Фрагментация IP и многоадресная передача

В конце раздела 20.4 мы отмечали, что в большинстве систем фрагментация широковещательной дейтаграммы не допускается по стратегическим соображениям. Фрагментация допускается при многоадресной передаче, что мы можем легко проверить, используя тот же файл с 2000-байтовой строкой:

macosx % udpcli01 224.0.1.1 < 2000line

from 172.24.37.78: xxxxxxx[...]

from 172.24.37.94: xxxxxxx[...]

Программа для получения анонсов сеанса многоадресной передачи, показанная в предыдущем разделе, могла только получать дейтаграммы многоадресной передачи. Теперь мы создадим простую программу, способную и отправлять, и получать дейтаграммы многоадресной передачи. Наша программа состоит из двух частей. Первая часть отправляет дейтаграмму многоадресной передачи определённой группе каждые 5 с. Эта дейтаграмма содержит имя узла отправителя и идентификатор процесса. Вторая часть программы — это бесконечный цикл, присоединяющийся к той группе, которой первая часть программы отправляет данные. В этом цикле выводится каждая полученная дейтаграмма (содержащая имя узла и идентификатор процесса отправителя). Это позволяет нам запустить программу на множестве узлов в локальной сети и посмотреть, какой узел получает дейтаграммы от каких отправителей.

В листинге 21.8 показана функция main нашей программы.

Листинг 21.8. Создание сокетов, вызов функции fork и запуск отправителя и получателя

//mcast/main.c

 1 #include "unp.h"

 2 void recv_all(int, socklen_t);

 3 void send_all(int. SA *, socklen_t);

 4 int

 5 main(int argc, char **argv)

 6 {

 7  int sendfd, recvfd;

 8  const int on = 1;

 9  socklen_t salen;

10  struct sockaddr *sasend, *sarecv;

11  if (argc != 3)

12   err_quit("usage: sendrecv ");

13  sendfd = Udp_client(argv[1], argv[2], (void**)&sasend, &salen);

14  recvfd = Socket(sasend->sa_family, SOCK_DGRAM, 0);

15  Setsockopt(recvfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));

16  sarecv = Malloc(salen);

17  memcpy(sarecv, sasend, salen);

18  Bind(recvfd, sarecv, salen);

19  Mcast_join(recvfd, sasend, salen, NULL, 0);

20  Mcast_set_loop(sendfd, 0);

21  if (Fork() == 0)

22   recv_all(recvfd, salen); /* дочерний процесс -> получение */

23  send_all(sendfd, sasend, salen); /* родитель -> отправка */

24 }

Мы создаем два сокета, один для отправки и один для получения. Нам нужно, чтобы принимающий сокет связался при помощи функции bind с группой и портом, допустим 239.255.1.2, порт 8888. (Вспомните, что мы могли просто связать универсальный IP-адрес и порт 8888, но связывание с определенным адресом многоадресной передачи предотвращает получение сокетом других дейтаграмм, которые могут прийти на порт получателя 8888.) Далее, нам нужно, чтобы принимающий сокет присоединился к группе. Отправляющий сокет будет отправлять дейтаграммы на этот же адрес многоадресной передачи и этот же порт, то есть на 239.255.1.2, порт 8888. Но если мы попытаемся использовать один сокет и для отправки, и для получения, то адресом отправителя для функции bind будет 239.255.1.2.8888 (здесь используется нотация netstat), а адресом получателя для функции sendto — также 239.255.1.2.8888. Но адрес отправителя, связанный с сокетом, становится IP-адресом отправителя дейтаграммы UDP, a RFC 1122 [10] запрещает дейтаграмме IP иметь IP-адрес отправителя, являющийся адресом многоадресной или широковещательной передачи. (См. также упражнение 21.2.) Следовательно, мы создаем два сокета: один для отправки, другой для получения.

Создание отправляющего сокета

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

Создание принимающего сокета и связывание (при помощи функции bind) с адресом многоадресной передачи и портом

14-18 Мы создаем принимающий сокет, используя то же семейство адресов, что и при создании отправляющего сокета, и устанавливаем параметр сокета SO_REUSEADDR, чтобы разрешить множеству экземпляров этой программы одновременно запускаться на узле. Затем мы выделяем в памяти пространство для структуры адреса этого сокета, копируем ее содержимое из структуры адреса отправляющего сокета (адрес и порт которого взяты из аргументов командной строки) и при помощи функции bind связываем адрес многоадресной передачи и порт с принимающим сокетом.

Присоединение к группе и выключение закольцовки

19-20 Мы вызываем нашу функцию mcast_join, чтобы присоединиться к группе на получающем сокете, а также нашу функцию mcast_set_loop, чтобы отключить закольцовку на отправляющем сокете. Для присоединения задаем имя интерфейса в виде пустого указателя и нулевой индекс интерфейса, что указывает ядру на необходимость выбрать интерфейс самостоятельно.

Функция fork и вызов соответствующих функций

21-23 Мы вызываем функцию fork, после чего дочерним процессом становится получающий цикл, а родительским — отправляющий.

Наша функция sendmail, отправляющая по одной дейтаграмме многоадресной передачи каждые 5 с, показана в листинге 21.9. Функция main передает в качестве аргументов дескриптор сокета, указатель на структуру адреса сокета, содержащую адрес получателя многоадресной передачи и порт, и длину структуры.

Листинг 21.9. Отправка дейтаграммы многоадресной передачи каждые 5 с

//mcast/send.c

 1 #include "unp.h"

 2 #include

 3 #define SENDRATE 5 /* отправка дейтаграмм каждые 5 с */

 4 void

 5 send_all(int sendfd, SA *sadest, socklen_t salen)

 6 {

 7  static char line[MAXLINE]; /* имя узла и идентификатор процесса */

 8  struct utsname myname;

 9  if (uname(&myname) < 0)

10   err_sys("uname error");

11  snprintf(line, sizeof(line), "%s, %d\n", myname, nodename, getpid());

12  for (;;) {

13   Sendto(sendfd, line, strlen(line), 0, sadest, salen);

14   sleep(SENDRATE);

15  }

16 }

Получение имени узла и формирование содержимого дейтаграммы

9-11 Мы получаем имя узла из функции uname и создаем строку вывода, содержащую это имя и идентификатор процесса.

Отправка дейтаграммы, переход в режим ожидания

12-15 Мы отправляем дейтаграмму и с помощью функции sleep переходим в состояние ожидания на 5 с.

Функция recv_all, содержащая бесконечный цикл получения, показана в листинге 21.10.

Листинг 21.10. Получение всех дейтаграмм многоадресной передачи для группы, к которой мы присоединились

//mcast/recv.c

 1 #include "unp.h"

 2 void

 3 recv_all(int recvfd, socklen_t salen)

 4 {

 5  int n;

 6  char line[MAXLINE + 1];

 7  socklen_t len;

 8  struct sockaddr *safrom;

 9  safrom = Malloc(salen);

10  for (;;) {

11   len = salen;

12   n = Recvfrom(recvfd, line, MAXLINE, 0, safrom, &len);

13   line[n] = 0; /* завершающий нуль */

14   printf("from %s: %s", Sock_ntop(safrom, len), line);

15  }

16 }

Размещение в памяти структуры адреса сокета

9 При каждом вызове функции recvfrom в памяти выделяется пространство для структуры адреса сокета, в которую записывается адрес отправителя.

Чтение и вывод дейтаграмм

10-15 Каждая дейтаграмма считывается функцией recvfrom, дополняется символом конца строки (то есть нулем) и выводится.

Пример

Мы запускаем программу в двух системах: freebsd4 и macosx. Каждая система видит пакеты, отправляемые другой.

freebsd4 % sendrecv 239.255.1.2 8888

from 172.24.37.78:51297: macosx, 21891

from 172.24.37.78:51297: macosx, 21891

from 172.24.37.78:51297: macosx, 21891

from 172.24.37.78:51297: macosx, 21891

macosx % sendrecv 239.255.1.2 8888

from 172.24.37.94.1215: freebsd4, 55372

from 172.24.37.94.1215: freebsd4, 55372

from 172.24.37.94.1215: freebsd4, 55372

from 172.24.37.94.1215: freebsd4, 55372

Исторически функции sendmsg и recvmsg использовались только для передачи дескрипторов через доменные сокеты Unix (см. раздел 15.7), но даже это происходило сравнительно редко. Однако в настоящее время популярность этих двух функций растет по двум причинам:

1. Элемент msg_flags, добавленный в структуру msghdr в реализации 4.3BSD Reno, возвращает приложению флаги сообщения. Эти флаги мы перечислили в табл. 14.2.

2. Вспомогательные данные используются для передачи все большего количества информации между приложением и ядром. В главе 27 мы увидим, что IPv6 продолжает эту тенденцию.

В качестве примера использования функции recvmsg мы напишем функцию recvfrom_flags, аналогичную функции recvfrom, но дополнительно позволяющую получить:

■ возвращаемое значение msg_flags;

■ адрес получателя полученной дейтаграммы (из параметра сокета IP_RECVDSTADDR);

■ индекс интерфейса, на котором была получена дейтаграмма (параметр сокета IP_RECVIF).

Чтобы можно было получить два последних элемента, мы определяем в нашем заголовке unp.h следующую структуру:

struct in_pktinfo {

 struct in_addr ipi_addr;    /* IPv4-адрес получателя */

 int            ipi_ifindex; /* индекс интерфейса, на котором была

                                получена дейтаграмма */

};

Мы выбрали имена структуры и ее элементов так, чтобы получить определенное сходство со структурой IPv6 in6_pktinfo, возвращающей те же два элемента для сокета IPv6 (см. раздел 22.8). Наша функция recvfrom_flags будет получать в качестве аргумента указатель на структуру in_pktinfo, и если этот указатель не нулевой, возвращать структуру через указатель.

Проблема построения этой структуры состоит в том, что неясно, что возвращать, если недоступна информация, которая должна быть получена из параметра сокета IP_RECVDSTADDR (то есть реализация не поддерживает данный параметр сокета). Обработать индекс интерфейса легко, поскольку нулевое значение может использоваться как указание на то, что индекс неизвестен. Но для IP-адреса все 32-разрядные значения являются действительными. Мы выбрали такое решение: адрес получателя 0.0.0.0 возвращается в том случае, когда действительное значение недоступно. Хотя это реальный IP-адрес, использовать его в качестве IP-адреса получателя не разрешается (RFC 1122 [10]). Он будет действителен только в качестве IP-адреса отправителя во время начальной загрузки узла, когда узел еще не знает своего IP-адреса.

ПРИМЕЧАНИЕ

К сожалению, Беркли-ядра принимают дейтаграммы, предназначенные для адреса 0.0.0.0 [128, с. 218-219]. Это устаревшие адреса широковещательной передачи, генерируемые ядрами 4.2BSD.

Первая часть нашей функции recvfrom_flags представлена в листинге 22.1. Эта функция предназначена для использования с сокетом UDP.

Листинг 22.1. Функция recvfrom_flags: вызов функции recvmsg

//adviо/recvfromflags.c

 1 #include "unp.h"

 2 #include /* макрос ALIGN для макроса CMSG_NXTHDR() */

 3 ssize_t

 4 recvfrom_flags(int fd, void *ptr, size_t nbytes, int *flagsp,

 5  SA *sa, socklen_t *salenptr, struct unp_in_pktinfo *pktp)

 6 {

 7  struct msghdr msg;

 8  struct iovec iov[1];

 9  ssize_t n;

10 #ifdef HAVE_MSGHDR_MSG_CONTROL

11  struct cmsghdr *cmptr;

12  union {

13   struct cmsghdr cm;

14   char control[CMSG_SPACE(sizeof(struct in_addr)) +

15    CMSG_SPACE(sizeof(struct unp_in_pktinfo))];

16  } control_un;

17  msg.msg_control = control_un.control;

18  msg.msg_controllen = sizeof(control_un.control);

19  msg.msg_flags = 0;

20 #else

21  bzero(&msg, sizeof(msg)); /* обнуление msg_accrightslen = 0 */

22 #endif

23  msg.msg_name = sa;

24  msg.msg_namelen = *salenptr;

25  iov[0].iov_base = ptr;

26  iov[0].iov_len = nbytes;

27  msg.msg_iov = iov;

28  msg.msg_iovlen = 1;

29  if ((n = recvmsg(fd, &msg, *flagsp)) < 0)

30   return(n);

31  *salenptr = msg.msg_namelen; /* возвращение результатов */

32  if (pktp)

33   bzero(pktp, sizeof(struct unp_in_pktinfo)); /* 0.0.0.0. интерфейс = 0 */

Подключаемые файлы

1-2 Использование макроопределения CMSG_NXTHDR требует подключения заголовочного файла .

Аргументы функции

3-5 Аргументы функции аналогичны аргументам функции recvfrom за исключением того, что четвертый аргумент является указателем на целочисленный флаг (так что мы можем возвратить флаги, возвращаемые функцией recvmsg), а седьмой аргумент новый: это указатель на структуру unp_in_pktinfo, содержащую IPv4-адрес получателя пришедшей дейтаграммы и индекс интерфейса, на котором дейтаграмма была получена.

Различия реализаций

10-22 При работе со структурой msghdr и различными константами MSG_ XXX мы встречаемся со множеством различий в реализациях. Одним из вариантов обработки таких различий может быть использование имеющейся в языке С возможности условного подключения (директива #ifdef). Если реализация поддерживает элемент msg_control, то выделяется пространство для хранения значений, возвращаемых параметрами сокета IP_RECVDSTADDR и IP_RECVIF, и соответствующие элементы инициализируются.

Заполнение структуры msghdr и вызов функции recvmsg

23-33 Заполняется структура msghdr и вызывается функция recvmsg. Значения элементов msg_namelen и msg_flags должны быть переданы обратно вызывающему процессу. Они являются аргументами типа «значение-результат». Мы также инициализируем структуру вызывающего процесса unp_in_pktinfo, устанавливая IP-адрес 0.0.0.0 и индекс интерфейса 0.

В листинге 22.2 показана вторая часть нашей функции.

Листинг 22.2. Функция recvfrom_flags: возвращаемые флаги и адрес получателя

//advio/recvfromflags.c

34 #ifndef HAVE_MSGHDR_MSG_CONTROL

35  *flagsp = 0; /* возвращение результатов */

36  return(n);

37 #else

38  *flagsp = msg.msg_flags; /* возвращение результатов */

39  if (msg.msg_controllen < sizeof(struct cmsghdr) ||

40   (msg.msg_flags & MSG_CTRUNC) || pktp == NULL)

41    return(n);

42   for (cmptr = CMSG_FIRSTHDR(&msg); cmptr != NULL;

43    cmptr = CMSG_NXTHDR(&msg, cmptr)) {

44 #ifdef IP_RECVDSTADDR

45    if (cmptr->cmsg_level == IPPROTO_IP &&

46     cmptr->cmsg_type == IP_RECVDSTADDR) {

47     memcpy(&pktp->ipi_addr, CMSG_DATA(cmptr),

48      sizeof(struct in_addr));

49     continue;

50    }

51 #endif

52 #ifdef IP_RECVIF

53    if (cmptr->cmsg_level == IPPROTO_IP && cmptr->cmsg_type == IP_RECVIF) {

54     struct sockaddr_dl *sdl;

55    sdl = (struct sockaddr_dl*)CMSG_DATA(cmptr);

56    pktp->ipi_ifindex = sdl->sdl_index;

57    continue;

58   }

59 #endif

60   err_quit("unknown ancillary data, len = %d, level = %d, type = %d",

61    cmptr->cmsg_len, cmptr->cmsg_level, cmptr->cmsg_type);

62  }

63  return(n);

64 #endif /* HAVE_MSGHDR_MSG_CONTROL */

65 }

34-37 Если реализация не поддерживает элемента msg_control, мы просто обнуляем возвращаемые флаги и завершаем функцию. Оставшаяся часть функции обрабатывает информацию, содержащуюся в структуре msg_control.

Возвращение при отсутствии управляющей информации

38-41 Мы возвращаем значение msg_flags и передаем управление вызывающей функции в том случае, если нет никакой управляющей информации, управляющая информация была обрезана или вызывающий процесс не требует возвращения структуры unp_in_pktinfo.

Обработка вспомогательных данных

42-43 Мы обрабатываем произвольное количество объектов вспомогательных данных с помощью макросов CMSG_FIRSTHDR и CMSG_NEXTHDR.

Обработка параметра сокета IP_RECVDSTADDR

47-54 Если в составе управляющей информации был возвращен IP-адрес получателя (см. рис. 14.2), он возвращается вызывающему процессу.

Обработка параметра сокета IP_RECVIF

55-63 Если в составе управляющей информации был возвращен индекс интерфейса, он возвращается вызывающему процессу. На рис. 22.1 показано содержимое возвращенного объекта вспомогательных данных.

Рис. 22.1. Объект вспомогательных данных, возвращаемый для параметра IP_RECVIF

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