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

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

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

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

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

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

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

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

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

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

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

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

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

ВПЕРЕД

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

6 m20jp-ml60tw.int.ipv6.ascc.net (2001:288:3b0::1b)

327.637 ms 326.897 ms 347.062 ms

7 hitachi1.otemachi.wide.ad.jp (2001:200:0:1800::9c4:2)

420.140 ms 426.592 ms 422.756 ms

8 pc3.yagami.wide.ad.jp (2001:200:0:1c04::1000:2000)

415.471 ms 418.308 ms 461.654 ms

9 gr2000.k2c.wide.ad.jp (2001:200:0:8002::2000:1)

416.581 ms 422.430 ms 427.692 ms

10 2001:200:0:4819:203:47ff:fea5:3085 (2001:200:0:4819:203:47ff:fea5:3085)

417.169 ms 434.674 ms 424.037 ms

28.7. Демон сообщений ICMP

Получение асинхронных ошибок ICMP на сокет UDP всегда было и продолжает оставаться проблемой. Ядро получает сообщения об ошибках ICMP, но они редко доставляются приложениям, которым необходимо о них знать. Мы видели, что для получения этих ошибок в API сокетов требуется присоединение сокета UDP к одному IP-адресу (см. раздел 8.11). Причина такого ограничения заключается в том, что единственная ошибка, возвращаемая функцией

recvfrom

, является целочисленным кодом

errno

, а если приложение посылает дейтаграммы по нескольким адресам, а затем вызывает

recvfrom

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

В данном разделе предлагается решение, не требующее никаких изменений в ядре. Мы предлагаем демон ICMP-сообщений

icmpd

, который создает символьный сокет ICMPv4 и символьный сокет ICMPv6 и получает все ICMP-сообщения, направляемые к ним ядром. Он также создает потоковый сокет домена Unix, связывает его (при помощи функции

bind

) с полным именем

/tmp/icmpd

и прослушивает входящие соединения (устанавливаемые при помощи функции

connect

) клиентов с этим сокетом. Схема соединений изображена на рис. 28.7.

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

Рис. 28.7. Демон icmpd: создание сокетов

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

bind

) с этим сокетом динамически назначаемый порт; для чего это делается, будет пояснено далее. Затем оно создает доменный сокет Unix и присоединяется (функция

connect

) к заранее известному полному имени файла демона. Это показано на рис. 28.8.

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

Рис. 28.8. Приложение создает свой сокет UDP и доменный сокет Unix

Далее приложение «передает» свой UDP-сокет демону через соединение домена Unix, используя технологию передачи дескрипторов, как показано в разделе 15.7. Такой подход позволяет демону получить копию сокета, так что он может вызвать функцию

getsockname

и получить номер порта, связанный с сокетом. На рис. 28.9 показана передача сокета.

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

Рис. 28.9. Пересылка сокета UDP демону через доменный сокет Unix

После того как демон получает номер порта, связанный с UDP-сокетом, он закрывает свою копию сокета, и мы возвращаемся к схеме, приведенной на рис. 28.8.

ПРИМЕЧАНИЕ

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

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

select

или

poll

, чтобы обеспечить ожидание прибытия данных либо на UDP-сокет, либо на доменный сокет Unix.

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

Листинг 28.20. Заголовочный файл unpicmpd.h

//icmpd/unpicmpd.h

1 #ifndef __unpicmp_h

2 #define __unpicmp_h

3 #include "unp.h"

4 #define ICMPD_PATH "/tmp/icmpd" /* известное имя сервера */

5 struct icmpd_err {

6 int icmpd_errno; /* EHOSTUNREACH, EMSGSIZE, ECONNREFUSED */

7 char icmpd_type; /* фактический тип ICMPv[46] */

8 char icmpd_code; /* фактический код ICMPv[46] */

9 socklen_t icmpd_len; /* длина последующей структуры sockaddr{} */

10 struct sockaddr_storage icmpd_dest; /* универсальная структура

sockaddr_storage */

11 };

12 #endif /* __unpicmp_h */

4-11

Определяются известное полное имя сервера и структура

icmpd_err

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

6-8

Проблема в том, что типы сообщений ICMPv4 отличаются численно (а иногда и концептуально) от типов сообщений ICMPv6 (см. табл. А.5 и А.6). Возвращаются реальные значения типа (type) и кода (code), но мы также отображаем соответствующие им значения

errno

(

icmpd_errno

), взятые из последнего столбца табл. А.5 и А.6. Приложение может использовать эти значения вместо зависящих от протокола значений ICMPv4 и ICMPv6. В табл. 28.1 показаны обрабатываемые сообщения ICMP и соответствующие им значения

errno

Таблица 28.1. Значения переменной icmpd_errno, сопоставляющей ошибки ICMPv4 и ICMPv6

icmpd_errno	Ошибка ICMPv4	Ошибка ICMPv6
ECONNREFUSED	Port unreachable (Порт недоступен)	Port unreachable (Порт недоступен)
EMSGSIZE	Fragmentation needed but DF bit set (Необходима фрагментация, но установлен бит DF)	Packet too big (Слишком большой пакет)
EHOSTUNREACH	Time exceeded (Превышено время передачи)	Time exceeded (Превышено время передачи)
EHOSTUNREACH	Source quench (Отключение отправителя)
EHOSTUNREACH	Все другие сообщения о недоступности получателя (Destination unreachable)	Все другие сообщения о недоступности получателя (Destination unreachable)