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

15 Connect(sockfd, (SA*)&servaddr, sizeof(servaddr));

16 ling.l_onoff = 1; /* для отправки сегмента RST при закрытии соединения */

17 ling.l_linger = 0;

18 Setsockopt(sockfd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));

19 Close(sockfd);

20 exit(0);

21 }

16-19 Как только соединение устанавливается, мы задаем параметр сокета SO_LINGER, устанавливая флаг l_onoffв единицу и обнуляя время l_linger. Как утверждалось в разделе 7.5, это вызывает отправку RST на сокете TCP при закрытии соединения. Затем с помощью функции closeмы закрываем сокет.

Потом мы изменяем наш сервер TCP, приведенный в листингах 6.3 и 6.4, с тем чтобы после сообщения функции selectо готовности прослушиваемого сокета для чтения, но перед вызовом функции acceptнаступала пауза. В следующем коде, взятом из начала листинга 6.4, две добавленные строки помечены знаком +.

if (FD_ISSET(listenfd, &rset)) { /* новое соединение */

+ printf("listening socket readable\n");

+ sleep(5);

clilen = sizeof(cliaddr);

connfd = Accept(listenfd, (SA*)&cliaddr, &clilen);

Здесь мы имитируем занятый сервер, который не может вызвать функцию acceptсразу же, как только функция selectсообщит, что прослушиваемый сокет готов для чтения. Обычно подобное замедление со стороны сервера не вызывает проблем (на самом деле именно для этих ситуаций предусмотрена очередь полностью установленных соединений). Но поскольку после установления соединения от клиента прибыл сегмент RST, у нас возникает проблема.

В разделе 5.11 мы отмечали, что когда клиент разрывает соединение до того, как сервер вызывает функцию accept, в Беркли-реализациях прерванное соединение не возвращается серверу, в то время как другие реализации должны возвращать ошибку ECONNABORTED, но часто вместо нее возвращают ошибку EPROTO. Рассмотрим Беркли-реализацию.

■ Клиент устанавливает соединение и затем прерывает его, как показано в листинге 16.14.

■ Функция selectсообщает процессу сервера, что дескриптор готов для чтения, но у сервера вызов функции acceptзанимает некоторое, хотя и непродолжительное, время.

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

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

■ Сервер вызывает функцию accept, но поскольку установленных соединений нет, он оказывается заблокирован.

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

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

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

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

2. Игнорировать следующие ошибки, возникающие при повторном вызове функции accept: EWOULDBLOCK(для Беркли-реализаций, когда клиент разрывает соединение), ECONNABORTED(для реализаций POSIX, когда клиент разрывает соединение), EPROTO(для реализаций SVR4, когда клиент разрывает соединение) и EINTR(если перехватываются сигналы).

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

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