Уильям Стивенс - UNIX: разработка сетевых приложений
Глава 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 это правильно.
Литература
Все документы RFC находятся в свободном доступе и могут быть получены по электронной почте, через анонимные FTP-серверы или WWW. Стартовая точка для поиска — http://www.ietf.org. Документы RFC расположены по адресу ftp://ftp.rfc-editor.org/in-notes. Отдельные документы RFC не снабжены адресами URL.
Пункты, помеченные как «интернет-проект», — это еще не законченные разработки IETF (Internet Engineering Task Force — целевая группа инженерной поддержки Интернета). После выхода этой книги в свет эти проекты, возможно, изменятся или будут опубликованы как RFC. Они находятся в свободном доступе, как и документы RFC. Основное хранилище интернет-проектов — http://www.ietf.org. Часть URL, содержащая имя файла, приведена рядом с названием каждого проекта, так как в ней содержится номер версии.
Для книг, статей и других источников, имеющих электронные версии, указаны адреса сайтов. Они могут меняться, поэтому следите за списком обновлений на сайте этой книги http://www.unpbook.com.
1. Albitz, P. and Liu, С. 2001. DNS and Bind, Fourth Edition. O'Reilly & Associates, Sebastopol, CA.
2. Allman, M., Floyd, S., and Partridge, C. 2002. "Increasing TCP's Initial Window," RFC 3390.
3. Allman, M., Ostermann, S., and Metz, C. W. 1998. "FTP Extensions for IPv6 and NATs," RFC 2428.
4. Allman, M., Paxson, V., and Stevens, W. R. 1999. "TCP Congestion Control," RFC 2581.
5. Almquist, P. 1992. "Type of Service in the Internet Protocol Suite," RFC 1349 (obsoleted by RFC 2474).
Обсуждается использование поля тип сервиса в заголовке IPv4.
6. Baker, F. 1995. "Requirements for IP Version 4 Routers," RFC 1812.
7. Borman, D. A. 1997a. "Re: Frequency of RST Terminated Connections," end2end-interest mailing list (http://www.unpbook.com/borman.97jan30.txt).
8. Borman, D. A. 1997b. "Re: SYN/RST cookies," tcp-impl mailing list (http://www.unpbook.com/borman.97jun06.txt).
9. Borman, D. A., Deering, S. E., and Hinden, R. 1999. "IPv6 Jumbograms," RFC 2675.
10. Braden, R. T. 1989. "Requirements for Internet Hosts —Communication Layers," RFC 1122.
Первая часть Host Requirements RFC: канальный уровень, IPv4, ICMPv4, IGMPv4, ARP, TCP и UDP.
11. Braden, R. T. 1992. "TIME-WAIT Assassination Hazards in TCP," RFC 1337.
12. Braden, R. T., Borman, D. A., and Partridge, C. 1988. "Computing the Internet checksum," RFC 1071.
13. Bradner, S. 1996. "The Internet Standards Process - Revision 3," RFC 2026.
14. Bush, R. 2001. "Delegation of IP6.ARPA," RFC 3152.
15. Butenhof, D. R. 1997. Programming with POSIX Threads. Addison-Wesley, Reading, MA.
16. Cain, В., Deering, S. E., Kouvelas, I., Fenner, В., and Thyagarajan, A. 2002. "Internet Group Management Protocol, Version 3," RFC 3376.
17. Carpenter, B. and Moore, K. 2001. "Connection of IPv6 Domains via IPv4 Clouds," RFC 3056.
18. CERT, 1996a. "UDP Port Denial-of-Service Attack," Advisory CA-96.01, Computer Emergency Response Team, Pittsburgh, PA.
19. CERT, 1996b. "TCP SYN Flooding and IP Spoofing Attacks," Advisory CA-96.21, Computer Emergency Response Team, Pittsburgh, PA.
20. Cheswick, W. R., Bellovin, S. M., and Rubin, A. D. 2003. Firewalls and Internet Security: Repelling the Wily Hacker, Second Edition. Addison-Wesley, Reading, MA.
21. Conta, A. and Deering, S. E. 1998. "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification," RFC 2463.
22. Conta, A. and Deering, S. E. 2001. "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification," draft-ietf-ipngwg-icmp-v3-02.txt (Internet Draft).
23. Crawford, M. 1998a. "Transmission of IPv6 Packets over Ethernet Networks," RFC 2464.
24. Crawford, M. 1998b. "Transmission of IPv6 Packets over FDDI Networks," RFC 2467.
25. Crawford, M., Narten, T., and Thomas, S. 1998. "Transmission of IPv6 Packets over Token Ring Networks," RFC 2470.
26. Deering, S. E. 1989. "Host extensions for IP multicasting," RFC 1112.
27. Deering, S. E. and Hinden, R. 1998. "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460.
28. Draves, R. 2003. "Default Address Selection for Internet Protocol version 6 (IPv6)," RFC 3484.
29. Eriksson, H. 1994. "MBONE: The Multicast Backbone," Communications of the ACM, vol. 37, no. 8, pp. 54–60.
30. Fink, R. and Hinden, R. 2003. "6bone (IPv6 Testing Address Allocation) Phase- out," draft-fink-6bone-phaseout-04.txt (Internet Draft).
31. Fuller, V., Li, T., Yu, J. Y., and Varadhan, K. 1993. "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy," RFC 1519.
