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

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

freebsd % traceroute www.kame.net

traceroute to orange.kame.net (2001:200:0:4819:203:47ff:fea5:3085): 30 hops max, 24 data bytes

1 3ffe:b80:3:9ad1::1 (3ffe:b80:3:9ad1::1) 107.437 ms 99.341 ms 103.477 ms

2 Viagenie-gw.int.ipv6.ascc.net (2001:288:3b0::55)

105.129 ms 89.418 ms 90.016 ms

3 gw-Viagenie.int.ipv6.ascc.net (2001:288:3b0::54)

302.300 ms 291.580 ms 289.839 ms

4 c7513-gw.int.ipv6.ascc.net (2001:288:3b0::c)

296.088 ms 298.600 ms 292.196 ms

5 m160-c7513.int.ipv6.ascc.net (2001:288:3b0::1e)

296.266 ms 314.878 ms 302.429 ms

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.

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

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

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

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

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

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

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

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

ПРИМЕЧАНИЕ

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

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

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