UNIX: разработка сетевых приложений - Уильям Стивенс
Шрифт:
Интервал:
Закладка:
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 completedn", 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 <Ipaddress>");
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