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

Если дескриптор готов для чтения или для записи, мы вызываем функцию , чтобы получить ошибку сокета ( ), ожидающую обработки. Если соединение завершилось успешно, это значение будет нулевым. Если при установлении соединения произошла ошибка, это значение является значением переменной , соответствующей ошибке соединения (например, , и т.д.). Мы также сталкиваемся с нашей первой проблемой переносимости. Если происходит ошибка, Беркли-реализации функции возвращают нуль, а ошибка, ожидающая обработки, возвращается в нашей переменной . Но в системе Solaris сама функция возвращает -1, а переменная при этом принимает значение, соответствующее ошибке, ожидающей обработки. В нашем коде обрабатываются оба сценария.

Мы восстанавливаем флаги, задающие статус файла, и возвращаемся. Если наша переменная errno имеет ненулевое значение в результате выполнения функции , это значение хранится в переменной , и функция возвращает -1.

Как мы сказали ранее, проблемы переносимости для функции

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

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

в листинге 16.7:

1. Вызвать функцию

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

2. Вызвать функцию

с нулевым значением аргумента . Если выполнение функции read окажется неудачным, функция connect выполнилась неудачно, и переменная errno из функции при этом указывает на причину неудачной попытки установления соединения. Если соединение успешно установлено, функция возвращает нуль.

3. Снова вызвать функцию

. Этот вызов окажется неудачным, и если ошибка — , сокет уже присоединен, а значит, первое соединение завершилось успешно.

К сожалению, неблокируемая функция

— это одна из самых сложных областей сетевого программирования с точки зрения переносимости. Будьте готовы к проблемам совместимости, особенно с более ранними реализациями. Более простой технологией является создание потока (см. главу 26) для обработки соединения.

Что происходит, если наш вызов функции

на обычном блокируемом сокете прерывается, скажем, перехваченным сигналом, прежде чем завершится трехэтапное рукопожатие TCP? Если предположить, что функция не перезапускается автоматически, то она возвращает ошибку . Но мы не можем снова вызвать функцию connect, чтобы добиться завершения установления соединения. Это приведет к ошибке .

Все, что требуется сделать в этом сценарии, — вызвать функцию

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

Первое практическое использование неблокируемой функции

относится к веб-клиенту Netscape (см. раздел 13.4 [112]). Клиент устанавливает соединение HTTP с веб-сервером и попадает на домашнюю страницу. На этой странице часто присутствуют ссылки на другие веб-страницы. Вместо того чтобы получать последовательно по одной странице за один раз, клиент может получить сразу несколько страниц, используя неблокируемые функции . На рис. 16.5 показан пример установления множества параллельных соединений. Сценарий, изображенный слева, показывает все три соединения, устанавливаемые одно за другим. Мы считаем, что первое соединение занимает 10 единиц времени, второе — 15, а третье — 4, что в сумме дает 29 единиц времени.

Рис. 16.5. Установление множества параллельных соединений

В центре рисунка показан сценарий, при котором мы выполняем два параллельных соединения. В момент времени 0 запускаются первые два соединения, а когда первое из них устанавливается, мы запускаем третье. Общее время сократилось почти вдвое и равно 15, а не 29 единицам времени, но учтите, что это идеальный случай. Если параллельные соединения совместно используют общий канал связи (допустим, клиент использует модем для соединения с Интернетом), то каждое из этих соединений конкурирует с другими за обладание ограниченными ресурсами этого канала связи, и время установления каждого соединения может возрасти. Например, время 10 может дойти до 15, 15 — до 20, а время 4 может превратиться в 6. Тем не менее общее время будет равно 21 единице, то есть все равно меньше, чем в последовательном сценарии.