После того, как сервер получил сообщение от функции

, и прежде, чем была вызвана функция , прибыл сегмент RST от клиента.

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

Сервер вызывает функцию

, но поскольку установленных соединений нет, он оказывается заблокирован.

Сервер останется блокированным в вызове функции

до тех пор, пока какой-нибудь другой клиент не установит с ним соединение. Но если сервер аналогичен показанному в листинге 6.4, в это время он заблокирован в вызове функции и не может обрабатывать никакие другие готовые дескрипторы.

ПРИМЕЧАНИЕ

Проблема в некоторой степени аналогична проблеме, называемой атакой типа «отказ в обслуживании», описанной в разделе 6.8. Однако в данном случае сервер выходит из состояния блокировки, как только другой клиент установит соединение.

Чтобы решить эту проблему, нужно соблюдать два следующих правила:

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

для определения того, готово ли соединение к обработке функцией accept.

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

: (для Беркли-реализаций, когда клиент разрывает соединение), (для реализаций POSIX, когда клиент разрывает соединение), (для реализаций SVR4, когда клиент разрывает соединение) и (если перехватываются сигналы).

В примере неблокируемого чтения и записи в разделе 16.2 использовался наш клиент

, который мы изменили для применения неблокируемого ввода-вывода на соединении TCP с сервером. Функция обычно используется с неблокируемым вводом-выводом для определения того момента, когда дескриптор станет готов для чтения или записи. Эта версия нашего клиента является самой быстродействующей из всех показанных версией, хотя требует нетривиального изменения кода. Затем мы показали, что проще разделить процесс клиента на две части при помощи функции . Мы используем ту же технологию при создании потоков в листинге 26.1.

Неблокируемая функция

позволяет нам во время трехэтапного рукопожатия TCP выполнять другие задачи вместо блокирования в вызове функции . К сожалению, с этими функциями также связана проблема совместимости, так как различные реализации по-разному указывают, успешно ли установлено соединение или произошла ошибка. Мы использовали неблокируемые соединения для создания нового клиента, аналогичного веб-клиенту, открывающему одновременно множество соединений TCP для уменьшения затрат времени при получении нескольких файлов от сервера. Подобное инициирование множества соединений может сократить временные затраты, но также является «недружественным по отношению к сети», поскольку не позволяет воспользоваться алгоритмом TCP, предназначенным для предотвращения перегрузки (congestion avoidance).

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

, а не функцию . Почему?

2. Что произойдет в листинге 16.6, если процесс сервера завершится преждевременно и дочерний процесс получит признак конца файла, но не уведомит об этом родительский процесс?

3. Что произойдет в листинге 16.6, если родительский процесс непредвиденно завершится до завершения дочернего процесса, и дочерний процесс затем считает конец файла на сокете?

4. Что произойдет в листинге 16.7, если мы удалим следующие две строки:

5. В разделе 16.3 мы сказали, что возможна ситуация, когда данные для сокета придут раньше, чем завершится функция

. Когда это может случиться?

Функция

традиционно являлась системным интерфейсом, используемым для всего, что не входило в какую-либо другую четко определенную категорию. POSIX постепенно избавляется от функции , создавая заменяющие ее функции-обертки и стандартизуя их функциональность. Например, доступ к интерфейсу терминала Unix традиционно осуществлялся с помощью функции , но в POSIX были созданы 12 новых функций для терминалов: для получения атрибутов терминала, для опустошения буферов ввода или вывода, и т.д. Аналогичным образом POSIX заменяет одну сетевую функцию : новая функция (см. раздел 24.3) заменяет команду . Тем не менее прочие сетевые команды остаются не стандартизованными и могут использоваться, например, для получения информации об интерфейсе и обращения к таблице маршрутизации и кэшу ARP (Address Resolution Protocol — протокол разрешения адресов).

В этой главе представлен обзор команд функции

, имеющих отношение к сетевому программированию, многие из которых зависят от реализации. Кроме того, некоторые реализации, включая системы, происходящие от 4.4BSD и Solaris 2.6, используют сокеты домена (маршрутизирующие сокеты) для выполнения многих из этих операций. Маршрутизирующие сокеты мы рассматриваем в главе 18.

Обычно сетевые программы (как правило, серверы) используют функцию

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