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

Name: UNIX: разработка сетевых приложений
Author: Стивенс Уильям Ричард--

На нашем литературном портале можно бесплатно читать книгу UNIX: разработка сетевых приложений, Стивенс Уильям Ричард-- . Жанр: ОС и Сети. Онлайн библиотека дает возможность прочитать весь текст и даже без регистрации и СМС подтверждения на нашем литературном портале bazaknig.info.

Жанр: Компьютеры и Интернет / ОС и Сети

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

Автор: Стивенс Уильям Ричард

Дата добавления: 16 январь 2020

Количество просмотров: 373

Читать онлайн

UNIX: разработка сетевых приложений читать книгу онлайн

UNIX: разработка сетевых приложений - читать бесплатно онлайн , автор Стивенс Уильям Ричард

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

Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних чтение данного контента СТРОГО ЗАПРЕЩЕНО! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту [email protected] для удаления материала

ВПЕРЕД

Перейти на страницу:

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

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