UNIX: разработка сетевых приложений — страница 39 из 42

Решения некоторых упражнений

Глава 1

1.3. В операционной системе Solaris получаем:

solaris % daytimetcpcli 127.0.0.1
socket error: Protocol not supported

Для получения дополнительной информации об этой ошибке сначала используем программу grep, чтобы найти строку Protocol not supported в заголовочном файле .

solaris % grep 'Protocol not supported' /usr/include/sys/errno.h
#define EPROTONOSUPPORT 120 /* Protocol not supported */

Это значение errno возвращается функцией socket. Далее смотрим в руководство пользователя:

solaris % man socket

В большинстве руководств пользователя в конце под заголовком «Errors» приводится дополнительная, хотя и лаконичная информация об ошибках.

1.4. Заменяем первое описание на следующее:

int sockfd, n, counter = 0;

Добавляем оператор

counter++;

в качестве первого оператора цикла while. Наконец, прежде чем прервать программу, выполняем

printf("counter = %d\n", counter);

На экран всегда выводится значение 1.

1.5. Объявим переменную i типа int и заменим вызов функции write на следующий:

for (i = 0; i < strlen(buff); i++)
 Write(connfd, &buff[i], 1);

Результат зависит от расположения клиентского узла и узла сервера. Если клиент и сервер находятся на одном узле, счетчик обычно равен 1. Это значит, что даже если сервер выполнит функцию write 26 раз, данные будут возвращены за одну операцию считывания (read). Но если клиент запущен в Solaris 2.5.1, а сервер в BSD/OS 3.0, счетчик обычно равен 2. Просмотрев пакеты Ethernet, мы увидим, что первый символ отправляется в первом пакете сам по себе, а следующий пакет содержит остальные 25 символов. (Обсуждение алгоритма Нагла в разделе 7.9 объясняет причину такого поведения.)

Цель этого примера — продемонстрировать, что разные реализации TCP по-разному поступают с данными, поэтому наше приложение должно быть готово считывать данные как поток байтов, пока не будет достигнут конец потока.

Глава 2

2.1 Зайдите на веб-страницу http://www.iana.org/numbers.htm и найдите журнал под названием «IP Version Number». Номер версии 0 зарезервирован, версии 1-3 не использовались, а версия 5 представляет собой потоковый протокол Интернета (Internet Stream Protocol).

2.2. Все RFC бесплатно доступны по электронной почте, через FTP или Web. Стартовая страница для поиска находится по адресу http://www.ietf.org. Одним из мест расположения RFC является каталог ftp://ftp.isi.edu/in-notes. Для начала следует получить файл с текущим каталогом RFC, обычно это файл rfc-index.txt. HTML-версия хранится в файле http://www.rfc-editor.org/rfc-index.html. Если с помощью какого-либо редактора осуществить поиск термина «stream» (поток) в указателе RFC, мы выясним, что RFC 1819 определяет версию 2 потокового протокола Интернета. Какую бы информацию, которая может содержаться в RFC, мы ни искали, для поиска следует использовать указатель (каталог) RFC.

2.3. В версии IPv4 при таком значении MSS генерируется 576-байтовая дейтаграмма (20 байт для заголовка IPv4 и 20 байт для заголовка TCP). Это минимальный размер буфера для сборки фрагментов в Ipv4.

2.4. В данном примере сервер (а не клиент) осуществляет активное закрытие.

2.5. Узел в сети Token Ring не может посылать пакет, содержащий больше, чем 1460 байт данных, поскольку полученное им значение MSS равно 1460. Узел в сети Ethernet может посылать пакет размером до 4096 байт данных, но не превышающий величину MTU исходящего интерфейса (Ethernet) во избежание фрагментации. Протокол TCP не может превысить величину MSS, объявленную другой стороной, но он всегда может посылать пакеты меньшего размера.

2.6. В разделе «Protocol Numbers» (номера протоколов) RFC «Assigned Numbers» («Присвоенные номера») указано значение 89 для протокола OSPF.

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

Глава 3

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

3.2. Указатель должен увеличиваться на количество считанных или записанных байтов, но в языке С нет возможности увеличивать указатели типа void (поскольку компилятору не известно, на какой тип данных указывает указатель).

Глава 4

4.1. Посмотрите на определение констант, начинающихся с INADDR_, кроме INADDR_ANY (состоит из нулевых битов) и INADDR_NONE (состоит из единичных битов). Например, адрес многоадресной передачи класса D INADDR_MAX_LOCAL_GROUP определяется как 0xe00000ff с комментарием «224.0.0.255», что явно указывает на порядок байтов узла.

4.2. Приведем новые строки, добавленные после вызова connect:

len = sizeof(cliaddr);
Getsockname(sockfd, (SA*)&cliaddr, &len);
printf("local addr: %s\n",
Sock_ntop((SA*)&cliaddr, len));

Это требует описания переменной len как socklen_t, a cliaddr как структуры struct sockaddr_in. Обратите внимание, что аргумент типа «значение-результат» для функции getsockname(len) должен быть до вызова функции инициализирован размером переменной, на которую указывает второй аргумент. Наиболее частая ошибка программирования при использовании аргументов типа «значение-результат» заключается в том, что про эту инициализацию забывают.

4.3. Когда дочерний процесс вызывает функцию close, счетчик ссылок уменьшается с 2 до 1, так что клиенту не посылается сегмент FIN. Позже, когда родительский процесс вызывает функцию close, счетчик ссылок уменьшается до нуля, и тогда сегмент FIN посылается.

4.4. Функция accept возвращает значение EINVAL, так как первый аргумент не является прослушиваемым сокетом.

4.5. Вызов функции listen без вызова функции bind присваивает прослушиваемому сокету динамически назначаемый порт.

Глава 5

5.1. Длительность состояния TIME_WAIT должна находиться в интервале между 1 и 4 минутами, что дает величину MSL от 30 с до 2 мин.

5.2. Наши клиент-серверные программы не работают с двоичными файлами. Допустим, что первые 3 байта в файле являются двоичной единицей (1), двоичным нулем (0) и символом новой строки. При вызове функции fgets в листинге 5.4 либо считывается MAXLINE - 1 символов, либо считываются символы до символа новой строки или до конца файла. В данном примере функция считает три символа, а затем прервет строку нулевым байтом. Но вызов функции strlen в листинге 5.4 возвращает значение 1, так как она остановится на первом нулевом байте. Один байт посылается серверу, но сервер блокируется в своем вызове функции readline, ожидая символа новой строки. Клиент блокируется, ожидая ответа от сервера. Такое состояние называется зависанием, или взаимной блокировкой: оба процесса блокированы и при этом каждый ждет от другого некоторого действия, которое никогда не произойдет. Проблема заключается в том, что функция fgets обозначает нулевым байтом конец возвращаемых ею данных, поэтому данные, которые она считывает, не должны содержать нулевой байт.

5.3. Программа Telnet преобразует входные строки в NVT ASCII (см. раздел 26.4 книги [111]), что означает прерывание каждой строки 2-символьной последовательностью CR (carriage return — возврат каретки) и LF (linefeed — новая строка). Наш клиент добавляет только разделитель строк (newline), который в действительности является символом новой строки (linefeed, LF). Тем не менее можно использовать клиент Telnet для связи с нашим сервером, поскольку наш сервер отражает каждый символ, включая CR, предшествующий каждому разделителю строк.

5.4. Нет, последние два сегмента из последовательности завершения соединения не посылаются. Когда клиент посылает серверу данные после уничтожения дочернего процесса сервера (ввод строки another line, см. раздел 5.12), сервер TCP отвечает сегментом RST. Сегмент RST прекращает соединение, а также предотвращает переход в состояние TIME_WAIT на стороне сервера (конец соединения, осуществивший активное закрытие).

5.5. Ничего не меняется, потому что процесс, запущенный на узле сервера, создает прослушиваемый сокет и ждет прибытия запросов на соединение. На третьем шаге мы посылаем сегмент данных, предназначенный для установленного соединения TCP (состояние ESTABLISHED). Наш сервер с прослушиваемым сокетом не увидит этот сегмент данных, и TCP сервера по-прежнему будет посылать клиенту сегмент RST.

5.6. В листинге Д.1[1] приведена программа. Запуск этой программы в Soalris генерирует следующий вывод:

solaris % tsigpipe 192.168.1.10
SIGPIPE received
write error: Broken pipe

Начальный вызов функции sleep и переход в режим ожидания на 2 с нужен, чтобы сервер времени и даты отправил ответ и закрыл свой конец соединения. Первая функция write отправляет сегмент данных серверу, который отвечает сегментом RST (поскольку сервер времени и даты полностью закрыл свой сокет). Обратите внимание, что наш TCP позволяет писать в сокет, получивший сегмент FIN. Второй вызов функции sleep позволяет получить от сервера сегмент RST, а во втором вызове функции write генерируется сигнал SIGPIPE. Поскольку наш обработчик сигналов возвращает управление, функция write возвращает ошибку EPIPE.

Листинг Д.1. Генерация SIGPIPE

//tcpcliserv/tsigpipe.c
 1 #include "unp.h"

 2 void
 3 sig_pipe(int signo)
 4 {
 5  printf("SIGPIPE received\n");
 6  return;
 7 }

 8 int
 9 main(int argc, char **argv)
10 {
11  int sockfd;
12  struct sockaddr_in servaddr;

13  if (argc != 2)
14   err_quit("usage: tcpcli ");

15  sockfd = Socket(AF_INET, SOCK_STREAM, 0);

16  bzero(&servaddr, sizeof(servaddr));
17  servaddr.sin_family = AF_INET;
18  servaddr.sin_port = htons(13); /* сервер времени и даты */
19  Inet_pton(AF_INET, argv[1], &servaddr.sin_addr);

20  Signal(SIGPIPE, sig_pipe);

21  Connect(sockfd, (SA*)&servaddr, sizeof(servaddr));

22  sleep(2);
23  Write(sockfd, "hello", 5);
24  sleep(2);
25  Write(sockfd, "world", 5);

26  exit(0);
27 }

5.7. В предположении, что узел сервера поддерживает модель системы с гибкой привязкой (см. раздел 8.8), все будет работать. Узел сервера примет IP-дейтаграмму (которая в данном случае содержит TCP-сегмент), прибывшую на самый левый канал, даже если IP-адрес получателя является адресом самого правого канала. Это можно проверить, если запустить наш сервер на узле linux (см. рис. 1.7), а затем запустить клиент на узле solaris, но на стороне клиента задать другой IP-адрес сервера (206.168.112.96). После установления соединения, запустив на стороне сервера программу netstat, мы увидим, что локальный IP-адрес является IP-адресом получателя из клиентского сегмента SYN, а не IP-адресом канала, на который прибыл сегмент SYN (как отмечалось в разделе 4.4).

5.8. Наш клиент был запущен в системе Intel с прямым порядком байтов, где 32-разрядное целое со значением 1 хранится так, как показано на рис. Д.1.

Рис. Д.1. Представление 32-разрядного целого числа 1 в формате прямого порядка байтов

Четыре байта посылаются на сокет в следующем порядке: A, A + 1, A + 2 и A + 3, и там хранятся в формате обратного порядка байтов, как показано на рис. Д.2.

Рис. Д.2. Представление 32-разрядного целого числа с рис. Д.1 в формате обратного порядка байтов

Значение 0x01000000 интерпретируется как 16 777 216. Аналогично, целое число 2, отправленное клиентом, интерпретируется сервером как 0x02000000, или 33 554 432. Сумма этих двух целых чисел равна 50 331 648, или 0x03000000. Когда это значение, записанное в обратном порядке байтов, отправляется клиенту, оно интерпретируется клиентом как целое число 3.

Но 32-разрядное целое число -22 представляется в системе с прямым порядком байтов так, как показано на рис. Д.3 (мы предполагаем, что используется поразрядное дополнение до двух для отрицательных чисел).

Рис. Д.3. Представление 32-разрядного целого числа -22 в формате прямого порядка байтов

В системе с обратным порядком байтов это значение интерпретируется как 0xeaffffff, или -352 521 537. Аналогично, представление числа -77 в прямом порядке байтов выглядит как 0xffffffb3, но в системах с обратным порядком оно представляется как 0xb3ffffff, или -1 275 068 417. Сложение, выполняемое сервером, приводит к результату 0x9efffffe, или -1 627 389 954. Полученное значение в обратном порядке байтов посылается через сокет клиенту, где в прямом порядке байтов оно интерпретируется как 0xfeffff9e, или -16 777 314 — это то значение, которое выводится в нашем примере.

5.9. Метод правильный (преобразование двоичных значений в сетевой порядок байтов), но нельзя использовать функции htonl и ntohl. Хотя символ l в названиях данных функций обозначает «long», эти функции работают с 32-разрядными целыми (раздел 3.4). В 64-разрядных системах long занимает 64 бита, и эти две функции работают некорректно. Для решения этой проблемы следует определить две новые функции hton64 и ntoh64, но они не будут работать в системах, представляющих значения типа long 32 битами.

5.10. В первом сценарии сервер будет навсегда блокирован при вызове функции readn в листинге 5.14, поскольку клиент посылает два 32-разрядных значения, а сервер ждет два 64-разрядных значения. В случае, если клиент и сервер поменяются узлами, клиент будет посылать два 64-разрядных значения, а сервер считает только первые 64 бита, интерпретируя их как два 32-разрядных значения. Второе 64-разрядное значение останется в приемном буфере сокета сервера. Сервер отправит обратно 32-разрядное значение, и клиент навсегда заблокируется в вызове функции readn в листинге 5.13, поскольку будет ждать для считывания 64-разрядное значение.

5.11. Функция IP-маршрутизации просматривает IP-адрес получателя (IP-адрес сервера) и пытается по таблице маршрутизации определить исходящий интерфейс и следующий маршрутизатор (см. главу 9 [111]). В качестве адреса отправителя используется первичный IP-адрес исходящего интерфейса, если сокет еще не связан с локальным IP-адресом.

Глава 6

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

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

6.3. Если оба дескриптора готовы для чтения, выполняется только первый тест — тест сокета. Но это не нарушает работоспособность клиента, а только лишь уменьшает его эффективность. Поэтому если при завершении функции select оба дескриптора готовы для чтения, первое условие if оказывается истинным, в результате чего сначала вызывается функция readline для считывания из сокета, а затем функция fputs для записи в стандартный поток вывода. Следующее условие if пропускается (поскольку мы добавили else), но функция select вызывается снова, сразу находит стандартное устройство ввода, готовое к чтению, и завершается. Суть в том, что условие готовности стандартного потока ввода для чтения сбрасывается считыванием из сокета, а не возвратом функции select.

6.4. Воспользуйтесь функцией getrlimit для получения значений константы RLIMIT_NOFILE, а затем вызовите функцию setrlimit для установки текущего гибкого предела (rlim_cur) равным жесткому пределу (rlim_max). Например, в Solaris 2.5 гибкий предел равен 64, но любой процесс может увеличить это значение до используемого по умолчанию значения жесткого предела (1024).

6.5. Серверное приложение непрерывно посылает данные клиенту, клиент TCP подтверждает их прием и сбрасывает.

6.6. Функция shutdown с аргументами SHUT_WR и SHUT_RDWR всегда посылает сегмент FIN, в то время как функция close посылает сегмент FIN только если в момент вызова функции close счетчик ссылок дескриптора равен 1.

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

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

Глава 7

7.2. Решение упражнения приведено в листинге Д.2. Вывод строки данных, возвращаемых сервером, был удален, поскольку это значение нам не нужно.

Листинг Д.2. Вывод размера приемного буфера сокета и MSS до и после установления соединения

//sockopt/rcvbuf.c
 1 #include "urp.h"
 2 #include  /* для TCP_MAXSEG */

 3 int
 4 main(int argc, char **argv)
 5 {
 6  int sockfd, rcvbuf, mss;
 7  socklen_t len;
 8  struct sockaddr_in servaddr;

 9  if (argc != 2)
10   err_quit("usage: rcvbuf ");

11  sockfd = Socket(AF_INET, SOCK_STREAM, 0);

12  len = sizeof(rcvbuf);
13  Getsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &rcvbuf, &len);
14  len = sizeof(mss);
15  Getsockopt(sockfd, IPPROTO_TCP, TCP_MAXSEG, &mss, &len);
16  printf("defaults: SO_RCVBUF = %d. MSS = %d\n", rcvbuf, mss);

17  bzero(&servaddr, sizeof(servaddr));
18  servaddr.sin_family = AF_INET;
19  servaddr.sin_port = htons(13); /* сервер времени и даты */
20  Inet_pton(AF_INET, argv[1], &servaddr.sin_addr);

21  Connect(sockfd, (SA*)&servaddr, sizeof(servaddr));

22  len = sizeof(rcvbuf);
23  Getsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &rcvbuf, &len);
24  len = sizeof(mss);
25  Getsockopt(sockfd, IPPROTO_TCP, TCP_MAXSEG, &mss, &len);
26  printf("after connect: SO_RCVBUF = %d, MSS = %d\n", rcvbuf, mss);

27  exit(0);
28 }

He существует какого-то одного «правильного» вывода для данной программы. Результаты зависят от системы. Некоторые системы (в особенности Solaris 2.5.1 и более ранние версии) всегда возвращают нулевой размер буфера сокета, не давая нам возможности увидеть, что происходит с этим значением в процессе соединения.

До вызова функции connect выводится значение MSS по умолчанию (часто 536 или 512), а значение, выводимое после вызова функции connect, зависит от возможных параметров MSS, полученных от собеседника. Например, в локальной сети Ethernet после выполнения функции connect MSS может иметь значение 1460. Однако после соединения (connect) с сервером в удаленной сети значение MSS может быть равно значению по умолчанию, если только ваша система не поддерживает обнаружение транспортной MTU. Если это возможно, запустите во время работы вашей программы программу tcpdump или подобную ей (см. раздел В.5), чтобы увидеть фактическое значение параметра MSS в сегменте SYN, полученном от собеседника.

Многие реализации после установления соединения округляют размер приемного буфера сокета в большую сторону, чтобы он было кратным MSS. Чтобы узнать размер приемного буфера сокета после установления соединения, можно исследовать пакеты с помощью программы типа tcpdump и посмотреть, каков размер объявленного окна TCP.

7.3. Разместите в памяти структуру linger по имени ling и проинициализируйте ее следующим образом:

str_cli(stdin, sockfd);

ling.l_onoff = 1;
ling.l_linger = 0;
Setsockopt(sockfd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));

exit(0);

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

readline error: Connection reset by peer

Клиентский сокет не должен проходить через состояние ожидания TIME_WAIT, даже если клиент выполняет активное закрытие.

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

7.5. Запускаем программу на узле без поддержки многоадресной передачи (MacOS X 10.2.6).

macosx % sock -s 9999 &запускаем первый сервер с универсальным адресом
[1] 29697
macosx % sock -s 172.24.37.78 9999пробуем второй сервер, но без -А
can't bind local address: Address already in use
macosx % sock -s -A 172.24.37.78 9999 &пробуем опять с -A: работает
[2] 29699
macosx % sock -s -A 127.0.0.1 9999 &третий сервер с -A; работает
[3] 29700
macosx % netstat -na | grep 9999
tcp4 0 0 127.0.0.1.9999     *.* LISTEN
tcp4 0 0 206.62.226.37.9999 *.* LISTEN
tcp4 0 0 *.9999             *.* LISTEN

7.6. Теперь попробуем проделать то же на узле с поддержкой многоадресной передачи, но без поддержки параметра SO_REUSEADDR (Solaris 9).

solaris % sock -s -u 8888 &запускаем первый
[1] 24051
solaris % sock -s -u 8888
can't bind local address: Address already in use
solaris % sock -s -u -A 8888 &снова пробуем запустить второй с -A:
                               работает
solaris % netstat -na | grep 8888мы видим дублированное связывание
*.8888 Idle
* 8888 Idle

В этой системе задавать параметр SO_REUSEADDR было необходимо только для второго связывания. Наконец, запускаем сценарий в MacOS X 10.2.6, где поддерживается как многоадресная передача, так и параметр SO_REUSEPORT. Сначала пробуем использовать SO_REUSEADDR для обоих серверов, но это не работает.

macosx % sock -u -s -A 7777 &
[1] 17610
macosx % sock -u -s -A 7777
can't bind local address: Address already in use

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

macosx % sock -u -s 8888 &
[1] 17612
macosx % sock -u -s -T 8888
can't bind local address: Address already in use

Наконец, задаем параметр SO_REUSEPORT для обоих серверов, и этот вариант работает.

macosx % sock -u -s -Т 9999 &
[1] 17614
macosx % sock -u -s -T 9999 &
[2] 17615
macosx % netstat -na | grep 9999
udp4 0 0 *.9999 *.*
udp4 0 0 *.9999 *.*

7.7. Этот параметр (-d) не делает ничего, поскольку программа ping использует ICMP-сокет, а параметр сокета SO_DEBUG влияет только на TCP-сокеты. Описание параметра сокета SO_DEBUG всегда было довольно расплывчатым, наподобие «этот параметр допускает отладку на соответствующем уровне протокола», и единственный уровень протокола, где реализуется данный параметр — это TCP.

7.8. Временная диаграмма приведена на рис. Д.4.

Рис. Д.4. Взаимодействие алгоритма Нагла с задержанными сегментами ACK

7.9. Установка параметра сокета TCP_NODELAY приводит к немедленной отправке данных из второй функции write, даже если имеется еще один небольшой пакет, ожидающий отправки. Это показано на рис. Д.5. Полное время в данном примере превышает 150 мс.

Рис Д.5. Предотвращение алгоритма Нагла путем установки параметра TCP_NODELAY

7.10. Как показано на рис. Д.6, преимущество данного решения состоит в уменьшении числа пакетов.

Рис. Д.6. Использование функции writev вместо параметра сокета TCP_NODELAY

7.11. В разделе 4.2.3.2 говорится: «задержка ДОЛЖНА быть меньше 0,5 с, а в потоке полноразмерных сегментов СЛЕДУЕТ использовать сегмент ACK по крайней мере для каждого второго сегмента». Беркли-реализации задерживают сегмент ACK не более, чем на 200 мс [128, с. 821].

7.12. Родительский процесс сервера в листинге 5.1 большую часть времени блокирован в вызове функции accept, а дочерний процесс в листинге 5.2 большую часть времени блокирован в вызове функции read, который содержится в функции readline. Проверка работоспособности с помощью параметра SO_KEEPALIVE не влияет на прослушиваемый сокет, поэтому в случае, если клиентский узел выйдет из строя, родительский процесс не пострадает. Функция read дочернего процесса возвратит ошибку ETIMEDOUT примерно через 2 ч после последнего обмена данными через соединение.

7.13. Клиент, приведенный в листинге 5.4, большую часть времени блокирован вызовом функции fgets, который, в свою очередь, блокирован операцией чтения из стандартной библиотеки ввода-вывода на стандартном устройстве ввода. Когда примерно через 2 ч после последнего обмена данными через соединение истечет время таймера проверки работоспособности и проверочные сообщения не выявят работоспособности сервера, ошибка сокета, ожидающая обработки, примет значение ETIMEDOUT. Но клиент блокирован вызовом функции fgets, поэтому он не увидит этой ошибки, пока не осуществит чтение или запись на сокете. Это одна из причин, по которой в главе 6 листинг 5.4 был изменен таким образом, чтобы использовать функцию select.

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

7.15. Происходит обмен только двумя сегментами, а не четырьмя. Вероятность того, что таймеры двух систем будут строго синхронизированы, очень мала, следовательно, на одном конце соединения таймер проверки работоспособности сработает немного раньше, чем на другом. Первый из сработавших таймеров посылает проверочное сообщение, заставляя другой конец послать в ответ сегмент ACK. Но получение проверочного сообщения приводит к тому, что таймеру проверки работоспособности с более медленными часами будет присвоено новое значение — он сдвинется на 2 ч вперед.

7.16 Изначально в API сокетов не было функции listen. Вместо этого четвертый аргумент функции socket содержал параметр сокета, а параметр SO_ACCEPTCONN использовался для задания прослушиваемого сокета. Когда добавилась функция listen, флаг остался, но теперь его может устанавливать только ядро [128, с. 456].

Глава 8

8.1. Да. Функция read возвращает 4096 байт данных, а функция recvfrom возвращает 2048 байт (первую из двух дейтаграмм). Функция recvfrom на сокете дейтаграмм никогда не возвращает больше одной дейтаграммы, независимо от того, сколько приложение запрашивает.

8.2. Если протокол использует структуры адреса сокета переменной длины, clilen может быть слишком длинным. В главе 15 будет показано, что это не вызывает проблем со структурами адреса доменного сокета Unix, но корректным решением будет использовать для функции sendto фактическую длину, возвращаемую функцией recvfrom.

8.4. Запуск программы ping с такими параметрами позволяет просмотреть ICMP-сообщения, получаемые узлом, на котором она запущена. Мы используем уменьшенное количество отправляемых пакетов вместо обычного значения 1 пакет в секунду, только чтобы уменьшить объем выводимой на экран информации. Если запустить наш UDP-клиент на узле solaris, указав IP-адрес сервера 192.168.42.1, а затем запустить программу ping, получим следующий вывод:

aix % ping -v -I 60 127.0.0.1
PING 127.0.0.1: {127.0.0.1}: 56 data bytes
64 bytes from 127 0.0.1: icmp_seq=0 ttl=255 time=0 ms
36 bytes from 192.168.42.1: Destination Port Unreachable
Vr HL TOS  Len   ID Fig  Off TTL Pro cks  Src Dst Data
4   5  00 0022 0007 0   0000  1e  11 c770 192 168 42.2 192.168.42.1
UDP: from port 40645. to port 9877 (decimal)

ПРИМЕЧАНИЕ

He все версии ping выводят сообщения об ICMP-ошибках, даже если задан параметр -v.

8.5. Прослушиваемый сокет может иметь приемный буфер определенного размера, но прослушиваемым TCP-сокетом данные никогда не принимаются. Большинство реализаций не выделяют заранее память под буферы отправки и приема. Размеры буферов сокета, определяемые параметрами SO_SNDBUF и SO_RCVBUF, являются предельными значениями для соответствующего сокета.

8.6. Запустим программу sock с параметром -u (использовать UDP) и параметром -l (определяет локальный адрес и порт) на многоинтерфейсном узле freebsd.

freebsd % sock -u -l 12.106.32.254.4444 192.168.42.2 8888
hello

Локальный IP-адрес подключен к Интернету (см. рис. 1.7), но чтобы достичь получателя, дейтаграмма должна выйти через другой интерфейс. Наблюдая за сетью с помощью программы tcpdump, мы увидим, что IP-адрес отправителя, связанный с клиентом, не является адресом исходящего интерфейса.

14:28:29.614846 12.106.32.254.444 > 192.168.42.2.8888. udp 6
14:28:29.615255 192.168.42.2 > 12 106.32.254: icmp: 192.168 42.2
udp port 8888 unreachable

8.7. Использование функции printf на стороне клиента приведет к возникновению задержки между отправками дейтаграмм, что позволит серверу получать большее количество дейтаграмм. Использование функции printf на стороне сервера приведет к тому, что сервер будет терять большее количество дейтаграмм.

8.8. Наибольший размер IPv4-дейтаграммы составляет 65 535 байт и ограничивается 16-разрядным полем полной длины, показанным на рис. А.1. IP-заголовок требует 20 байт, UDP-заголовок — 8 байт, и для пользовательских данных остается не более 65 507 байт. В IPv6 (без поддержки джумбограмм) размер IP-заголовка составляет 40 байт, и под пользовательские данные отводится 65 487 байт.

В листинге Д.3 приведена новая версия dg_cli. Если забыть установить размер буфера отправки, Беркли-ядра возвратят из функции sendto ошибку EMSGSIZE, поскольку размер буфера отправки сокета обычно меньше, чем максимально возможный размер UDP-дейтаграммы (чтобы убедиться в этом, выполните упражнение 7.1).

Листинг Д.3. Запись дейтаграммы UDP/IPv4 максимального размера

//udpcliserv/dgclibig.c
 1 #include "unp.h"

 2 #undef MAXLINE
 3 #define MAXLINE 65507

 4 void
 5 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)
 6 {
 7  int size;
 8  char sendline[MAXLINE], recvline[MAXLINE + 1];
 9  ssize_t n;

10  size = 70000;
11  Setsockopt(sockfd, SOL_SOCKET, SO_SNDBUF, &size, sizeof(size));
12  Setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &size, sizeof(size));

13  Sendto(sockfd, sendline, MAXLINE, 0, pservaddr, servlen);

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

15  printf("received %d bytes\n", n);
16 }

Но если установить размеры буферов сокета клиента, как показано в листинге Д.3, и запустить программу, сервер ничего не возвратит. С помощью программы tcpdump можно убедиться, что клиентская дейтаграмма отправляется серверу, но если в сервер поместить функцию printf, вызов функции recvfrom не возвратит дейтаграмму. Проблема заключается в том, что приемный буфер UDP-сокета сервера меньше, чем посланная нами дейтаграмма, поэтому дейтаграмма отбрасывается и не доставляется на сокет. В системах BSD/OS это можно проверить, запустив программу netstat -s и проверив счетчик, указывающий количество дейтаграмм, отброшенных из-за переполнения буферов сокета (dropped due to full socket buffers), до и после получения нашей длинной дейтаграммы. Решением является модификация сервера путем задания размеров буферов приема и отправки сокета.

В большинстве сетей дейтаграмма длиной 65 535 байт фрагментируется. Как отмечалось в разделе 2.9, IP-уровнем должен поддерживаться размер буфера для сборки фрагментов, равный всего лишь 576 байт. Поэтому некоторые узлы не получат дейтаграмму максимального размера, посылаемую в данном упражнении. Кроме того, во многих Беркли-реализациях, включая 4.4BSD-Lite2, имеется ошибка, связанная со знаковыми типами данных, которая не позволяет UDP принимать дейтаграммы больше, чем 32 767 байт (см. строка 95, с. 770 [128]).

Глава 9

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

9.2. На стороне сервера выполняется автоматическое закрытие после закрытия ассоциации клиентом. SCTP не поддерживает состояние неполного закрытия, поэтому когда клиент вызывает close, все подготовленные сервером данные сбрасываются и ассоциация закрывается.

9.3. Сокет типа «один-к-одному» требует вызова connect, поэтому когда собеседнику отсылается сегмент COOKIE, никаких данных в буфере отправки быть еще не может. Сокет типа «один-ко-многим» допускает отправку данных с одновременной установкой соединения. Поэтому сегмент COOKIE в этом случае может быть совмещен с сегментом DATA.

9.4. Собеседник, с которым устанавливается ассоциация, может прислать данные только в том случае, если у него будет готов сегмент DATA до того, как соединение будет установлено, то есть если на обеих сторонах используются сокеты типа «один-ко-многим» и каждая сторона выполняет операцию send с неявной установкой соединения. Такой процесс установки ассоциации называется коллизией пакетов INIT и подробно описывается в главе 4 [117].

9.5. В некоторых случаях не все связанные адреса могут быть переданы собеседнику. В частности, если приложение связало с сокетом как частные, так и общие IP-адреса, собеседник получит информацию только об общих IP-адресах. Еще одним примером являются локальные в рамках канала адреса IPv6, которые не обязательно сообщаются собеседнику.

Глава 10

10.1 Если функция sctp_sendmsg возвращает ошибку, сообщение не будет отправлено, а приложение вызовет функцию sctp_recvmsg и заблокируется в ней навсегда, ожидая ответного сообщения, которое никогда не придет.

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

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

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

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

10.4. Алгоритм Нагла (управляемый параметром сокета SCTP_NODELAY, см. раздел 7.10) вызывает проблемы только при передаче данных небольших объемов. Если данные передаются порциями такого размера, что SCTP вынужден передавать их немедленно, никакого замедления быть не может. Установка небольшого размера out_sz исказит результаты, потому что в некоторых случаях передача будет задерживаться до получения выборочных уведомлений от собеседника. Поэтому при передаче данных небольшого размера алгоритм Нагла следует отключать.

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

Сокет типа «один-ко-многим» позволяет устанавливать ассоциации неявно. Для изменения параметров ассоциации необходимо вызвать sendmsg со вспомогательными данными. Фактически при этом обязательно использовать неявное установление ассоциации.

Глава 11

11.1. В листинге Д.4 приведена программа, вызывающая функцию gethostbyaddr.

Листинг Д.4. Изменение листинга 11.1 для вызова функции gethostbyaddr

//names/hostent2.c
 1 #include "unp.h"

 2 int
 3 main(int argc, char **argv)
 4 {
 5  char *ptr, **pptr;
 6  char str[INET6_ADDRSTRLEN];
 7  struct hostent *hptr;

 8  while (--argc > 0) {
 9   ptr = *++argv;
10   if ( (hptr = gethostbyname(ptr)) == NULL) {
11    err_msg("gethostbyname error for host: %s: %s",
12     ptr, hstrerror(h_errno));
13    continue;
14   }
15   printf("official hostname: %s\n", hptr->h_name);
16   for (pptr = hptr->h_aliases; *pptr != NULL; pptr++)
17    printf(" alias: %s\n", *pptr);

18   switch (hptr->h_addrtype) {
19   case AF_INET:
20 #ifdef AF_INET6
21   case AF_INET6:
22 #endif
23    pptr = hptr->h_addr_list;
24    for (; *pptr != NULL; pptr++) {
25     printf("\taddress: %s\n",
26      Inet_ntop(hptr->h_addrtype, *pptr, str, sizeof(str)));

27     if ((hptr = gethostbyaddr(*pptr, hptr->h_length,
28      ptr->h_addrtype)) == NULL)
29      printf("\t(gethostbyaddr failed)\n");
30     else if (hptr->h_name != NULL)
31      printf("\tname = %s\n", hptr->h_name);
32     else
33      printf("\t(no hostname returned by gethostbyaddr)\n");
34    }
35    break;

36   default:
37    err_ret("unknown address type");
38    break;
39   }
40  }
41  exit(0);
42 }

Эта программа корректно работает на узле с единственным IP-адресом. Если запустить программу из листинга 11.1 на узле с четырьмя IP-адресами, то получим:

freebsd % hostent cnn.com
official hostname: cnn.com
address: 64.236.16.20
address: 64.236.16.52
address: 64.236.16.84
address: 64.236.16.116
address: 64 236.24.4
address: 64.236.24.12
address: 64.236.24.20
address: 64.236.24.28

Но если запустить программу из листинга Д.4 на том же узле, в выводе будет только первый IP-адрес:

freebsd % hostent2 cnn.com
official hostname: cnn.com
address: 64.236.24.4
name = www1.cnn.com

Проблема заключается в том, что две функции, gethostbyname и gethostbyaddr, совместно используют одну и ту же структуру hostent, как было показано в разделе 11.18. Когда наша новая программа вызывает функцию gethostbyaddr, она повторно использует данную структуру вместе с областью памяти, на которую структура указывает (массив указателей h_addr_list), стирая три оставшиеся IP-адреса, возвращаемые функцией gethostbyname.

11.2. Если ваша система не поддерживает повторно входимую версию функции gethostbyaddr (см. раздел 11.19), то прежде чем вызывать функцию gethostbyaddr, вам следует создать копию массива указателей, возвращаемых функцией gethostbyname, и данных, на которые указывает этот массив.

11.3. Сервер chargen отправляет клиенту данные до тех пор, пока клиент не закрывает соединение (то есть пока вы не завершите выполнение клиента).

11.4. Эта возможность поддерживается некоторыми распознавателями, но переносимая программа не может использовать ее, потому что POSIX никак ее не оговаривает. В листинге Д.5 приведена измененная версия. Порядок тестирования строки с именем узла имеет значение. Сначала мы вызываем функцию inet_pton, поскольку она обеспечивает быстрый тест «внутри памяти» (in-memory) для проверки, является ли строка допустимым IP-адресом в точечно-десятичной записи. Только если тест заканчивается неудачно, мы запускаем функцию gethostbyname, которая обычно требует некоторых сетевых ресурсов и времени.

Если строка является допустимым IP-адресом в точечно-десятичной записи, мы создаем свой массив указателей (addrs) на один IP-адрес, оставив без изменений цикл, использующий pptr.

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

Листинг Д.5. Допускаем как использование IP-адреса в точечно-десятичной записи, так и задание имени узла, номера порта или имени службы

//names/daytimetcpcli2.c
 1 #include "unp.h"

 2 int
 3 main(int argc, char **argv)
 4 {
 5  int sockfd, n;
 6  char recvline[MAXLINE + 1];
 7  struct sockaddr_in servaddr;
 8  struct in_addr **pptr, *addrs[2];
 9  struct hostent *hp;
10  struct servent *sp;

11  if (argc != 3)
12   err_quit("usage: daytimetcpcli2 ");

13  bzero(&servaddr, sizeof(servaddr));
14  servaddr.sin_family = AF_INET;

15  if (inet_pton(AF_INET, argv[1], &servaddr.sin_addr) == 1) {
16   addrs[0] = &servaddr.sin_addr;
17   addrs[1] = NULL;
18   pptr = &addrs[0];
19  } else if ((hp = gethostbyname(argv[1])) != NULL) {
20   pptr = (struct in_addr**)hp->h_addr_list;
21  } else
22   err_quit("hostname error for %s: %s", argv[1], hstrerror(h_errno));

23  if ((n = atoi(argv[2])) > 0)
24   servaddr.sin_port = htons(n);
25  else if ((sp = getservbyname(argv[2], "tcp")) != NULL)
26   servaddr.sin_port = sp->s_port;
27  else
28   err_quit("getservbyname error for %s", argv[2]);

29  for (; *pptr != NULL; pptr++) {
30   sockfd = Socket(AF_INET, SOCK_STREAM, 0);

31   memmove(&servaddr.sin_addr, *pptr, sizeof(struct in_addr));
32   printf("trying %s\n",
33    Sock_ntop((SA*)&servaddr, sizeof(servaddr)));

34   if (connect(sockfd, (SA*)&servaddr, sizeof(servaddr)) == 0)
35    break; /* успех */
36   err_ret("connect error");
37   close(sockfd);
38  }
39  if (*pptr == NULL)
40   err_quit("unable to connect");

41  while ((n = Read(sockfd, recvline, MAXLINE)) > 0) {
42   recvline[n] = 0; /* завершающий нуль */
43   Fputs(recvline, stdout);
44  }
45  exit(0);
46 }

11.5. Программа приведена в листинге Д.6.

Листинг Д.6. Модификация листинга 11.2 для работы с IPv4 и IPv6

//names/daytimetcpcli3.c
 1 #include "unp.h"

 2 int
 3 main(int argc, char **argv)
 4 {
 5  int sockfd, n;
 6  char recvline[MAXLINE + 1];
 7  struct sockaddr_in servaddr;
 8  struct sockaddr_in6 servaddr6;
 9  struct sockaddr *sa;
10  socklen_t sal en;
11  struct in_addr **pptr;
12  struct hostent *hp;
13  struct servent *sp;

14  if (argc != 3)
15   err_quit("usage: daytimetcpcli3 ");

16  if ((hp = gethostbyname(argv[1])) == NULL)
17   err_quit("hostname error for %s: %s", argv[1], hstrerror(h_errno));

18  if ((sp = getservbyname(argv[2], "tcp")) == NULL)
19   err_quit("getservbyname error for %s", argv[2]);

20  pptr = (struct in_addr**)hp->h_addr_list;
21  for (; *pptr != NULL; pptr++) {
22   sockfd = Socket(hp->h_addrtype, SOCK_STREAM, 0);

23   if (hp->h_addrtype == AF_INET) {
24    sa = (SA*)&servaddr;
25    salen = sizeof(servaddr);
26   } else if (hp->h_addrtype == AF_INET6) {
27    sa = (SA*)&servaddr6;
28    salen = sizeof(servaddr6);
29   } else
30    err_quit("unknown addrtype %d", hp->h_addrtype);

31   bzero(sa, salen);
32   sa->sa_family = hp->h_addrtype;
33   sock_set_port(sa, salen, sp->s_port);
34   sock_set_addr(sa, salen, *pptr);

35   printf("trying %s\n", Sock_ntop(sa, salen));

36   if (connect(sockfd, sa, salen) == 0)
37    break; /* успех */
38   err_ret("connect error");
39   close(sockfd);
40  }
41  if (*pptr == NULL)
42   err_quit("unable to connect");

43  while ((n = Read(sockfd, recvline, MAXLINE)) > 0) {
44   recvline[n] = 0; /* завершающий нуль */
45   Fputs(recvline, stdout);
46  }
47  exit(0);
48 }

Используем значение h_addrtype, возвращаемое функцией gethostbyname, для определения типа адреса. Также используем функции sock_set_port и sock_set_addr (см. раздел 3.8), чтобы установить два соответствующих поля в структуре адреса сокета.

Эта программа работает, однако имеется два ограничения. Во-первых, мы должны обрабатывать все различия, следя за h_addrtype и задавая соответствующим образом sa или salen. Более удачным решением было бы иметь библиотечную функцию, которая не только просматривает имя узла и имя службы, но и заполняет всю структуру адреса сокета (например, getaddrinfo, см. раздел 11.6). Во-вторых, эта программа компилируется только на узлах с поддержкой IPv6. Чтобы ее можно было откомпилировать на узле, поддерживающем только IPv4, следует добавить в код огромное количество директив #ifdef, что, несомненно, усложнит программу.

11.7. Разместите в памяти большой буфер (превышающий по размеру любую структуру адреса сокета) и вызовите функцию getsockname. Третий аргумент является аргументом типа «значение-результат», возвращающим фактический размер адресов протоколов. К сожалению, это допускают только структуры адреса сокета с фиксированной длиной (IPv4 и IPv6). Нет гарантии, что этот буфер будет работать с протоколами, которые могут вернуть структуру адреса сокета переменной длины (доменные сокеты Unix, см. главу 15).

11.8. Сначала размещаем в памяти массивы, содержащие имя узла и имя службы:

char host[NI_MAXHOST], serv[NI_MAXSERV];

После того как функция accept возвращает управление, вызываем вместо функции sock_ntop функцию getnameinfo:

if (getnameinfo(cliaddr, len, host, NI_MAXHOST, serv, NI_MAXSERV,
 NI_NUMERICHOST | NI_NUMERICSERV) == 0)
 printf("connection from %s.%s\n", host, serv);

Поскольку мы имеем дело с сервером, определяем флаги NI_NUMERICHOST и NI_NUMERICSERV, чтобы избежать поиска в DNS и /etc/services.

11.9. Первая проблема состоит в том, что второй сервер не может связаться (bind) с тем же портом, что и первый сервер, поскольку не установлен параметр сокета SO_REUSEADDR. Простейший способ справиться с такой ситуацией — создать копию функции udp_server, переименовать ее в udp_server_reuseaddr, сделать так, чтобы она установила параметр сокета, и вызывать ее в сервере.

11.10. Когда клиент выводит Trying 206.62.226.35..., функция gethostname возвращает IP-адрес. Пауза перед этим выводом означает, что распознаватель ищет имя узла. Вывод Connected to bsdi.unpbook.com. значит, что функция connect возвратила управление. Пауза между этими двумя выводами говорит о том, что функция connect пытается установить соединение.

Глава 12

12.1. Далее приведен сокращенный листинг. Обратите внимание, что клиент FTP в системе freebsd всегда пытается использовать команду EPRT (независимо от версии IP), но если это не срабатывает, то он пробует команду PORT.

freebsd % ftp aix-4
Connected to aix-4.unpbook.com.
220 aix FTP server ...
...
230 Guest login ok. access restrictions apply.
ftp>debug
Debugging on (debug=1).
ftp>passive
Passive mode: off; fallback to active mode= off
ftp>dir
---> EPRT |1|192 168.42.1|50484|
500 'EPRT |1|192.168.42.1|50484|' command not understood.
disabling epsv4 for this connection
---> PORT 192.168.42.1.197.52
200 PORT command successful.
---> LIST
150 Opening ASCII mode data connection for /bin/ls
...
freebsd % ftp ftp.kame.net
Trying 2001.200:0:4819:203:47ff:fea5:3085...
Connected to orange.kame.net.
220 orange.kame.net FTP server ...
...
230 Guest login ok. access restrictions apply.
ftp>debug
Debugging on (debug=1).
ftp>passive
Passive mode: off; fallback to active mode: off.
ftp>dir
---> EPRT |2|3ffe:b80:3:9ad1::2|50480|
200 EPRT command successful
---> LIST
150 Opening ASCII mode data connection for '/bin/ls'.

Глава 13

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

13.2. TCP-версии серверов echo, discard и chargen запускаются как дочерние процессы, после того как демон inetd вызовет функцию fork, поскольку эти три сервера работают, пока клиент не прервет соединение. Два других TCP-сервера, time и daytime, не требуют использования функции fork, поскольку эти службы легко реализовать (получить текущую дату, преобразовать ее, записать и закрыть соединение). Эти два сервера обрабатываются непосредственно демоном inetd. Все пять UDP-служб обрабатываются без использования функции fork, поскольку каждая из них генерирует единственную дейтаграмму в ответ на клиентскую дейтаграмму, которая запускает эту службу. Эти пять служб обрабатываются напрямую демоном inetd.

13.3. Это известная атака типа «отказ в обслуживании» [18]. Первая дейтаграмма с порта 7 заставляет сервер chargen отправить дейтаграмму обратно на порт 7. На эту дейтаграмму приходит эхо-ответ, и серверу chargen посылается другая дейтаграмма. Происходит зацикливание. Одним из решений, реализованным в системе BSD/OS, является игнорирование дейтаграмм, направленных любому внутреннему серверу, если номер порта отправителя пришедшей дейтаграммы принадлежит одному из внутренних серверов. Другим решением может быть запрещение этих внутренних служб — либо с помощью демона inetd на каждом узле, либо на маршрутизаторе, связывающем внутреннюю сеть организации с Интернетом.

13.4. IP-адрес и номер порта клиента могут быть получены из структуры адреса сокета, заполняемой функцией accept.

Причина, по которой демон inetd не делает этого для UDP-сокета, состоит в том, что чтение дейтаграмм (recvfrom) осуществляется с помощью функции exec сервером, а не самим демоном inetd.

Демон inetd может считать дейтаграмму с флагом MSG_PEEK (см. раздел 14.7), только чтобы получить IP-адрес и номер порта клиента, но оставляет саму дейтаграмму для чтения серверу.

Глава 14

14.1. Если не установлен обработчик, первый вызов функции signal будет возвращать значение SIG_DFL, а вызов функции signal для восстановления обработчика просто вернет его в исходное состояние.

14.3. Приведем цикл for:

for (;;) {
 if ((n = Recv(sockfd, recvline, MAXLINE, MSG_PEEK)) == 0)
  break; /* сервер закрыл соединение */

 Ioctl(sockfd, FIONREAD, &npend);
 printf("%d bytes from PEEK, %d bytes pending\n", n, npend);

 n = Read(sockfd, recvline, MAXLINE);
 recvline[n] = 0; /* завершающий нуль */
 Fputs(recvline, stdout);
}

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

exit(main(argc, argv));

Следовательно, вызывается функция exit, а затем и программа очистки стандартного ввода-вывода.

Глава 15

15.1. Функция unlink удаляет имя файла из файловой системы, и когда клиент позже вызовет функцию connect, она не выполнится. Это не влияет на прослушиваемый сокет сервера, но клиенты не смогут выполнить функции connect после вызова функции unlink.

15.2. Клиент не сможет соединиться с сервером с помощью функции connect, даже если полное имя существует, поскольку для успешного соединения с помощью функции connect доменный сокет Unix должен быть открыт и связан с этим полным именем (см. раздел 15.4).

15.3. При выводе адреса протокола клиента путем вызова функции sock_ntop мы получим сообщение datagram from (no pathname bound) (дейтаграмма от (имя не задано)), поскольку по умолчанию с сокетом клиента не связывается никакое имя.

Одним из решений является проверить доменный сокет Unix в функциях udp_client и udp_connect и связать с сокетом при помощи функции bind временное полное имя. Это приведет к зависимости от протокола в библиотечной функции, но не в нашем приложении.

15.4. Даже если мы заставим сервер вернуть в функции write 1 байт на его 26- байтовый ответ, использование функции sleep на стороне клиента гарантирует, что все 26 сегментов будут получены до вызова функции read, в результате чего функция read вернет полный ответ. Это еще одно подтверждение того, что TCP является потоком байтов с отсутствием границ записей.

Чтобы использовать доменные протоколы Unix, запускаем клиент и сервер с двумя аргументами командной строки /lосаl (или /unix) и /tmp/daytime (или любое другое временное имя, которое вы хотите использовать). Ничего не изменится: 26 байт будут возвращаться функцией read каждый раз, когда будет запускаться клиент.

Поскольку для каждой функции send сервер определяет флаг MSG_EOR, каждый байт рассматривается как логическая запись, и функция read при каждом вызове возвращает 1 байт. Причина в том, что Беркли-реализации поддерживают флаг MSG_EOR по умолчанию. Однако этот факт не документирован и не может использоваться в серийном коде. В данном примере мы используем эту особенность, чтобы показать разницу между потоком байтов и ориентированным на записи протоколом. С точки зрения реализации, каждая операция вывода идет в mbuf (буфер памяти) и флаг MSG_EOR сохраняется ядром вместе с mbuf, когда mbuf переходит из отправляющего сокета в приемный буфер принимающего сокета. Когда вызывается функция read, флаг MSG_EOR все еще присоединен к каждому mbuf, так что основная подпрограмма ядра read (поддерживающая флаг MSG_EOR, поскольку некоторые протоколы используют этот флаг) сама возвращает каждый байт. Если бы вместо read мы использовали recvmsg, флаг MSG_EOR возвращался бы в поле msg_flags каждый раз, когда recvmsg возвращала бы 1 байт. Такой подход в TCP не срабатывает, поскольку отправляющий TCP не анализирует флаг MSG_EOR в отсылаемом mbuf и в любом случае у нас нет возможности передать этот флаг принимающему TCP в TCP-заголовке. (Выражаем благодарность Мату Томасу (Matt Thomas) за то, что он указал нам это недокументированное «средство».)

15.5. В листинге Д.7 приведена реализация данной программы.

Листинг Д.7. Определение фактического количества собранных в очередь соединений для различных значений аргумента backlog

//debug//backlog.c
 1 #include "unp.h"

 2 #define PORT 9999
 3 #define ADDR "127 0.0.1"
 4 #define MAXBACKLOG 100

 5 /* глобальные переменные */
 6 struct sockaddr_in serv;
 7 pid_t pid; /* дочерний процесс */

 8 int pipefd[2];
 9 #define pfd pipefd[1] /* сокет родительского процесса */
10 #define cfd pipefd[0] /* сокет дочернего процесса */

11 /* прототипы функций */
12 void do_parent(void);
13 void do_child(void);

14 int
15 main(int argc, char **argv)
16 {
17  if (argc != 1)
18   err_quit("usage: backlog");

19  Socketpair(AF_UNIX, SOCK_STREAM, 0, pipefd);

20  bzero(&serv, sizeof(serv));
21  serv.sin_family = AF_INET;
22  serv.sin_port = htons(PORT);
23  Inet_pton(AF_INET, ADDR, &serv.sin_addr);

24  if ((pid = Fork()) == 0)
25   do_child();
26  else
27  do_parent();

28  exit(0);
29 }

30 void
31 parent_alrm(int signo)
32 {
33  return; /* прерывание блокированной функции connect() */
34 }

35 void
36 do_parent(void)
27 {
38  int backlog, j, k, junk, fd[MAXBACKLOG + 1];

39  Close(cfd);
40  Signal(SIGALRM, parent_alrm);

41  for (backlog = 0; backlog <= 14; backlogs) {
42   printf("backlog = %d. ", backlog);
43   Write(pfd, &backlog. sizeof(int)); /* сообщение значения дочернему процессу */
44   Read(pfd, &junk, sizeof(int)); /* ожидание дочернего процесса */

45   for (j = 1; j <= MAXBACKLOG; j++) {
46    fd[j] = Socket(AF_INET, SOCK_STREAM, 0);
47    alarm(2);
48    if (connect(fd[j], (SA*)&serv, sizeof(serv)) < 0) {
49     if (errno != EINTR)
50      err_sys("connect error, j = %d", j);
51     printf("timeout, %d connections completed\n", j - 1);
52     for (k = 1; k <= j; k++)
53      Close(fd[k]);
54     break; /* следующее значение backlog */
55    }
56    alarm(0);
57   }
58   if (j > MAXBACKLOG)
59    printf("Id connections?\n", MAXBACKLOG);
60  }
61  backlog = -1; /* сообщаем дочернему процессу, что все сделано */
62  Write(pfd, &backlog, sizeof(int));
63 }

64 void
65 do_child(void)
66 {
67  int listenfd, backlog, junk;
68  const int on = 1;

69  Close(pfd);

70  Read(cfd, &backlog, sizeof(int)); /* ожидание родительского процесса */
71  while (backlog >= 0) {
72   listenfd = Socket(AF_NET, SOCK_STREAM, 0);
73   Setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
74   Bind(listenfd, (SA*)&serv, sizeof(serv));
75   Listen(listenfd, backlog); /* начало прослушивания */

76   Write(cfd, &junk, sizeof(int)); /* сообщение родительскому процессу */

77   Read(cfd, &backlog, sizeof(int)); /* ожидание родительского процесса */
78   Close(listenfd); /* также закрывает все соединения в очереди */
79  }
80 }

Глава 16

16.1. Дескриптор используется совместно родительским и дочерним процессами, поэтому его счетчик ссылок равен 2. Если родительский процесс вызывает функцию close, счетчик ссылок уменьшается с 2 до 1, и пока он больше нуля, сегмент FIN не посылается. Еще одна цель вызова функции shutdown — послать сегмент FIN, даже если дескриптор больше нуля.

16.2. Родительский процесс продолжит запись в сокет, получивший сегмент FIN, а первый сегмент, посланный серверу, вызовет получение сегмента RST в ответ. После этого функция write пошлет родительскому процессу сигнал SIGPIPE, как показано в разделе 5.12.

16.3. Когда дочерний процесс вызывает функцию getppid для отправки сигнала SIGTERM, возвращаемый идентификатор процесса будет равен 1. Это указывает на процесс init, наследующий все продолжающие работать дочерние процессы, родительские процессы которых завершились. Дочерний процесс будет пытаться послать сигнал процессу init, не имея необходимых прав доступа. Но если не исключается, что данный клиент будет запущен с правами привилегированного пользователя, позволяющими посылать сигналы процессу init, то возвращенное функцией getppid значение должно быть проверено перед отправкой сигнала.

16.4. Если удалить эти две строки, вызывается функция select. Но функция select немедленно завершится, поскольку соединение установлено и сокет открыт для записи. Эта проверка и оператор goto предотвращают ненужный вызов функции select.

16.5. Это может случиться, если сервер отправляет данные сразу, как только завершается его функция accept, и если узел клиента занят, когда приходит второй пакет трехэтапного рукопожатия для завершения соединения со стороны клиента (см. рис. 2.5). SMTP-серверы, например, немедленно отсылают клиенту сообщение по новому соединению, прежде чем произвести из него считывание.

Глава 17

17.1. Нет, это не имеет значения, поскольку первые три элемента объединения в листинге 17.1 являются структурами адреса сокета.

Глава 18

18.1. Элемент sdl_nlen будет равен 5, а элемент sdl_alen будет равен 8. Для этого требуется 21 байт, поэтому размер округляется до 24 байт [128, с. 89] в предположении, что используется 32-разрядная архитектура.

18.2. На этот сокет никогда не посылается ответ от ядра. Данный параметр сокета (SO_USELOOPBACK) определяет, посылает ли ядро ответ отправляющему процессу, как показано на с. 649-650 [128]. По умолчанию этот параметр включен, поскольку большинство процессов ожидают ответа. Но отключение данного параметра препятствует отправке ответов отправителю.

Глава 20

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

20.2. Когда в FreeBSD обработчик сигналов записывает байт в канал, а затем завершается, функция select возвращает ошибку EINTR. Она вызывается заново и при завершении сообщает о возможности чтения из канала.

Глава 21

21.1.Если запустить программу, то она не выведет ничего. Для предотвращения получения многоадресных дейтаграмм сервером, не ожидающим их, ядро не доставляет дейтаграммы на сокет, не выполнявший никаких многоадресных операций (в частности, не присоединявшийся к группам). Происходит следующее. В адресе получателя UDP-дейтаграммы стоит 224.0.0.1 — это группа всех узлов, в которой должны состоять узлы, поддерживающие многоадресную передачу. UDP-дейтаграмма посылается как многоадресный кадр Ethernet, и все узлы с поддержкой многоадресной передачи должны получить ее, поскольку все они входят в указанную группу. Все отвечающие узлы передают полученную UDP-дейтаграмму серверу времени и даты (обычно он является частью демона inetd), даже если этот сокет не находится в группе. Однако ядро сбрасывает полученную дейтаграмму, потому что процесс, связанный с портом сервера времени и даты, не установил параметры многоадресной передачи.

21.2. В листинге Д.8 показаны простые изменения функции main для связывания (bind) с адресом многоадресной передачи и портом 0.

Листинг Д.8. Функция main UDP-клиента, осуществляющая связывание с адресом многоадресной передачи

//mcast/udpcli06.c
 1 #include "unp.h"

 2 int
 3 main(int argc, char **argv)
 4 {
 5  int sockfd;
 6  socklen_t salen;
 7  struct sockaddr *cli, *serv;

 8  if (argc != 2)
 9   err_quit("usage: udpcli06 ");

10  sockfd = Udp_client(argv[1], "daytime", (void**)&serv, &salen);

11  cli = Malloc(salen);
12  memcpy(cli, serv, salen); /* копируем структуру адреса сокета */
13  sock_set_port(cli, salen, 0); /* и устанавливаем порт в 0 */
14  Bind(sockfd, cli, salen);

15  dg_cli(stdin, sockfd, serv, salen);

16  exit(0);
17 }

К сожалению, все три системы, на которых проводилась проверка — FreeBSD 4.8, MacOS X и Linux 2.4.7, — позволяют использовать функцию bind, а затем посылают UDP-дейтаграммы с IP-адресом многоадресной передачи отправителя.

21.3. Если мы запустим программу ping для группы узлов 224.0.0.1 на нашем узле aix, получим следующий вывод:

solaris % ping 224.0.0.1
PING 224.0.0.1: 56 data bytes
64 bytes from 192.168.42.2: icmp_seq=0 ttl=255 time=0 ms
64 bytes from 192.168.42.1: icmp_seq=0 ttl=64 time=1 ms (DUP!)
^C
----224.0.0.1 PING Statistics----
1 packets transmitted. 1 packets received. +1 duplicates. 0% packet loss
round-trip min/avg/max = 0/0/0 ms

Ответили оба узла в правой сети Ethernet на рис. 1.7.

ПРИМЕЧАНИЕ

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

freebsd % sysctl net.inet.icmp.bmcastecho=1

21.5. Величина 1 073 741 824 преобразуется в значение с плавающей точкой и делится на 4 294 967 296, что дает значение 0,250. В результате умножения на 1 000 000 получаем значение 250 000 в микросекундах, а это одна четверть секунды. Наибольшая дробная часть получается при делении 4 294 967 295 на 429 4967 296 и составляет 0,99 999 999 976 716 935 634. Умножая это число на 1 000 000 и отбрасывая дробную часть, получаем 999 999 — наибольшее значение количества микросекунд.

Глава 22

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

22.2. Да, если ответ содержит 0 байт пользовательских данных (например, структура hdr).

22.3. Поскольку функция select не изменяет структуру timeval, которая определяет ее ограничение по времени, нам следует заметить время отправки первого пакета (оно возвращается в миллисекундах функцией rtt_ts). Если функция select сообщает, что сокет готов к чтению, заметьте текущее время, а если функция recvmsg вызывается повторно, вычислите новый тайм-аут для функции select.

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

22.5. Вызов функции getaddrinfо без аргумента имени узла и без флага AI_PASSIVE заставляет эту функцию считать, что используется локальный адрес 0::1 (для IPv6) или 127.0.0.1 (для IPv4). Напомним, что структура адреса сокета IPv6 возвращается функцией getaddrinfo перед структурой адреса сокета IPv4 при условии, что поддерживается протокол IPv6. Если узел поддерживает оба протокола, вызов функции socket в udp_client закончится успешно при указании семейства протоколов AF_INET6.

В листинге Д.9 приведена не зависящая от протокола версия программы.

Листинг Д.9. Не зависящая от протокола версия программы из раздела 22.6

//advio/udpserv04.c
 1 #include "unpifi.h"

 2 void mydg_echo(int, SA*, socklen_t);

 3 int
 4 main(int argc, char **argv)
 5 {
 6  int sockfd, family, port;
 7  const int on = 1;
 8  pid_t pid;
 9  socklen_t salen;
10  struct sockaddr *sa, *wild;
11  struct ifi_info *ifi, *ifihead;

12  if (argc == 2)
13   sockfd = Udp_client(NULL, argv[1], (void**)&sa, &salen);
14  else if (argc == 3)
15   sockfd = Udp_client(argv[1], argv[2], (void**)&sa, &salen);
16  else
17   err_quit("usage; udpserv04 [  ] ");
18  family = sa->sa_family;
19  port = sock_get_port(sa, salen);
20  Close(sockfd); /* хотим узнать семейство, порт salen */

21  for (ifihead = ifi = Get_ifi_info(family, 1),
22   ifi ! = NULL; ifi = ifi->ifi_next) {

23   /* связывание с многоадресными адресами */
24   sockfd = Socket(family, SOCK_DGRAM, 0);
25   Setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));

26   sock_set_port(ifi->ifi_addr, salen, port);
27   Bind(sockfd, ifi->ifi_addr, salen);
28   printf("bound %s\n", Sock_ntop(ifi->ifi_addr, salen));

29   if ((pid = Fork()) == 0) { /* дочерний процесс */
30    mydg_echo(sockfd, ifi->ifi_addr, salen);
31    exit(0); /* никогда не выполняется */
32   }
33   if (ifi->ifi_flags & IFF_BROADCAST) {
34    /* попытка связывания с широковещательным адресом */
35    sockfd = Socket(family, SOCK_DGRAM, 0);
36    Setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));

37    sock_set_port(ifi->ifi_brdaddr, salen, port);
38    if (bind(sockfd, ifi->ifi_brdaddr, salen) < 0) {
39     if (errno == EADDRINUSE) {
40      printf("EADDRINUSE: %s\n",
41       Sock_ntop(ifi->ifi_brdaddr, salen));
42      Close(sockfd);
43      continue;
44     } else
45      err_sys("bind error for %s",
46     Sock_ntop(ifi->ifi_brdaddr, salen));
47    }
48    printf ("bound %s\n", Sock_ntop(ifi->ifi_brdaddr, salen));

49    if ((pid = Fork()) == 0) { /* дочерний процесс */
50     mydg_echo(sockfd, ifi->ifi_brdaddr, salen);
51     exit(0); /* никогда не выполняется */
52    }
53   }
54  }

55  /* связывание с универсальным адресом */
56  sockfd = Socket(family, SOCK_DGRAM, 0);
57  Setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));

58  wild = Malloc(salen);
59  memcpy(wild, sa, salen); /* копирует семейство и порт */
60  sock_set_wild(wild, salen);

61  Bind(sockfd, wild, salen);
62  printf("bound %s\n", Sock_ntop(wild, salen));

63  if ((pid = Fork()) == 0) { /* дочерний процесс */
64   mydg_echo(sockfd, wild, salen);
65   exit(0); /* никогда не выполняется */
66  }
67  exit(0);
68 }

69 void
70 mydg_echo(int sockfd, SA *myaddr, socklen_t salen)
71 {
72  int n;
73  char mesg[MAXLINE];
74  socklen_t len;
75  struct sockaddr *cli;

76  cli = Malloc(salen);

77  for (;;) {
78   len = salen;
79   n = Recvfrom(sockfd, mesg, MAXLINE, 0, cli, &len);
80   printf("child %d, datagram from %s",
81    getpid(), Sock_ntop(cli, len));
82   printf(", to %s\n", Sock_ntop(myaddr, salen));

83   Sendto(sockfd, mesg, n, 0, cli, len),
84  }
85 }

Глава 24

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

24.2. В листинге Д.10 приведена версия программы с использованием функции poll.

Листинг Д.10. Версия программы из листинга 24.4, использующая функцию poll вместо функции select

//oob/tcprecv03p.c
 1 #include "unp.h"

 2 int
 3 main(int argc, char **argv)
 4 {
 5  int listenfd, connfd, n, justreadoob = 0;
 6  char buff[100];
 7  struct pollfd pollfd[1];

 8  if (argc == 2)
 9   listenfd = Tcp_listen(NULL, argv[1], NULL);
10  else if (argc == 3)
11   listenfd = Tcp_listen(argv[1], argv[2], NULL);
12  else
13   err_quit("usage: tcprecv03p [  ] ");

14  connfd = Accept(listenfd, NULL, NULL);

15  pollfd[0].fd = connfd;
16  pollfd[0].events = POLLRDNORM;
17  for (;;) {
18   if (justreadoob == 0)
19    pollfd[0].events |= POLLRDBAND;

20   Poll(pollfd, 1, INFTIM);

21   if (pollfd[0].revents & POLLRDBAND) {
22    n = Recv(connfd, buff, sizeof(buff) - 1, MSG_OOB);
23    buff[n] = 0; /* завершающий нуль */
24    printf("read %d OOB byte: %s\n", n, buff);
25    justreadoob = 1;
26    pollfd[0].events &= ~POLLRDBAND; /* отключение бита */
27   }
28   if (pollfd[0].revents & POLLRDNORM) {
29    if ((n = Read(connfd, buff, sizeof(buff) - 1)) == 0) {
30     printf("received EOF\n");
31     exit(0);
32    }
33    buff[n] = 0; /* завершающий нуль */
34    printf("read %d bytes %s\n", n, buff);
35    justreadoob = 0;
36   }
37  }
38 }

Глава 25

25.1. Нет, такая модификация приведет к ошибке. Проблема состоит в том, что nqueue уменьшается до того, как завершается обработка элемента массива dg[iget], что позволяет обработчику сигналов считывать новую дейтаграмму в данный элемент массива.

Глава 26

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

26.2. Обмена двумя последними сегментами завершения TCP-соединения (сегмент FIN сервера и сегмент ACK клиента в ответ на сегмент FIN сервера) не произойдет. Это переведет клиентский конец соединения в состояние FIN_WAIT_2 (см. рис. 2.4). Беркли-реализации прервут работу клиентского конца, если он остался в этом состоянии, по тайм-ауту через 11 минут [128, с. 825–827]. У сервера же в конце концов закончатся дескрипторы.

26.3. Это сообщение будет выводиться основным программным потоком в том случае, когда он считывает из сокета признак конца файла и при этом другой поток продолжает работать. Простейший способ выполнить это — объявить другую внешнюю переменную по имени done, инициализируемую нулем. Прежде чем функция copyto программного потока вернет управление, она установит эту переменную в 1. Основной программный поток проверит эту переменную, и если она равна нулю, выведет сообщение об ошибке. Поскольку значение переменной устанавливает только один программный поток, нет необходимости в синхронизации.

Глава 27

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

27.2. Мы бы поместили EOL (нулевой байт) в конец буфера.

27.3. Поскольку программа ping создает символьный (неструктурированный) сокет (см. главу 28), она получает полный IP-заголовок, включая все IP-параметры, для каждой дейтаграммы, которую она считывает с помощью функции recvfrom.

27.4. Потому что сервер rlogind запускается демоном inetd (см. раздел 13.5).

27.5. Проблема заключается в том, что пятый аргумент функции setsockopt является указателем на длину, а не самой длиной. Эта ошибка, вероятно, была выявлена, когда впервые использовались прототипы ANSI С.

Ошибка оказалась безвредной, поскольку, как отмечалось, для отключения параметра сокета IP_OPTIONS можно либо задать пустой указатель в качестве четвертого аргумента, либо установить нулевое значение в пятом аргументе (длине) [128, с. 269].

Глава 28

28.1. Недоступными являются поле номера версии и поле следующего заголовка в IPv6. Поле полезной длины доступно либо как аргумент одной из функций вывода, либо как возвращаемое значений одной из функций ввода, но если требуется параметр увеличенного поля данных (jumbo payload option), сам параметр приложению недоступен. Заголовок фрагментации также недоступен приложению.

28.2. В конце концов приемный буфер клиентского сокета заполнится, и при этом функция демона write будет заблокирована. Мы не хотим, чтобы это произошло, поскольку демон тогда перестанет обрабатывать данные на всех своих сокетах. Простейшим решением является следующее: демон должен сделать свой конец соединения домена Unix с клиентом неблокируемым. Для этого демон должен вызывать функцию write вместо функции-обертки Write и игнорировать ошибку EWOULDBLOCK.

28.3. По умолчанию Беркли-ядра допускают широковещательную передачу через символьный сокет [128, с. 1057]. Поэтому параметр сокета SO_BROADCAST необходимо определять только для UDP-сокетов.

28.4. Наша программа не проверяет адреса многоадресной передачи и не устанавливает параметр сокета IP_MULTICAST_IF. Следовательно, ядро выбирает исходящий интерфейс, вероятно, просматривая таблицу маршрутизации для 224.0.0.1. Мы также не устанавливаем значение поля IP_MULTICAST_TTL, поэтому по умолчанию оно равно 1, и это правильное значение.

Глава 29

29.1. Этот флаг означает, что буфер перехода устанавливается функцией sigsetjmp (см. листинг 29.6). Хотя этот флаг может казаться лишним, существует вероятность, что сигнал может быть доставлен после того, как устанавливается обработчик ошибок, но перед тем как вызывается функция sigsetjmp. Даже если программа не вызывает генерацию сигнала, сигнал всё равно может быть сгенерирован другим путем (например, как в случае с командой kill).

Глава 30

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

30.2. Для передачи дескриптора действительно можно вместо потокового сокета использовать сокет дейтаграмм. В случае сокета дейтаграмм родительский процесс не получает признака конца файла на своем конце канала, когда дочерний процесс прерывается преждевременно, но для этих целей родительский процесс может использовать сигнал SIGCHLD. Следует иметь в виду, что эта ситуация отличается от случая с применением нашего демона icmpd (см. раздел 28.7): тогда между клиентом и сервером не было иерархических отношений (родительский процесс — дочерний процесс), поэтому использование признака конца файла было единственным способом для сервера обнаружить исчезновение клиента.

Глава 31

31.1. Здесь предполагается, что по умолчанию для протокола осуществляется нормальное завершение при закрытии потока, и для TCP это правильно.

Литература