Еще большую путаницу в эту ситуацию вносит то, что в Беркли-реализации структура данных ядра, содержащая значение, которое сравнивается с первым аргументом функции socket (элемент dom_family структуры domain [128, с. 187]), сопровождается комментарием, где сказано, что в этой структуре содержится значение AF_. Но некоторые структуры domain внутри ядра инициализированы с помощью константы AF_ [128, с. 192], в то время как другие — с помощью PF_ [128, с. 646], [112, с. 229].
Еще одно историческое замечание. Страница руководства по 4.2BSD от июля 1983 года, посвященная функции socket, называет ее первый аргумент af и перечисляет его возможные значения как константы AF_.
Наконец, отметим, что POSIX задает первый аргумент функции socket как значение PF_, а значение AF_ использует для структуры адреса сокета. Но далее в структуре addrinfo определяется только одно значение семейства (см. раздел 11.2), предназначенное для использования либо в вызове функции socket, либо в структуре адреса сокета!
В целях согласования с существующей практикой программирования мы используем в тексте только константы AF_
, хотя вы можете встретить и значение PF_
, в основном в вызовах функции socket
.
Функция connect
используется клиентом TCP для установления соединения с сервером TCP.
#include
int connect(int sockfd , const struct sockaddr * servaddr ,
socklen_t addrlen );
Возвращает: 0 в случае успешного выполнения функции, -1 в случае ошибки
Аргумент sockfd
— это дескриптор сокета, возвращенный функцией socket
. Второй и третий аргументы — это указатель на структуру адреса сокета и ее размер (см. раздел 3.3). Структура адреса сокета должна содержать IP-адрес и номер порта сервера. Пример применения этой функции был представлен в листинге 1.1.
Клиенту нет необходимости вызывать функцию bind
(которую мы описываем в следующем разделе) до вызова функции connect
: при необходимости ядро само выберет и динамически назначаемый порт, и IP-адрес отправителя.
В случае сокета TCP функция connect
инициирует трехэтапное рукопожатие TCP (см. раздел 2.6). Функция возвращает значение, только если установлено соединение или произошла ошибка. Возможно несколько ошибок:
1. Если клиент TCP не получает ответа на свой сегмент SYN, возвращается сообщение ETIMEDOUT
. 4.4BSD, например, отправляет один сегмент SYN, когда вызывается функция connect
, второй — 6 с спустя, и еще один — через 24 с [128, с. 828]. Если ответ не получен в течение 75 с, возвращается ошибка.
Некоторые системы позволяют администратору устанавливать значение времени ожидания; см. приложение Е [111].
2. Если на сегмент SYN сервер отвечает сегментом RST, это означает, что ни один процесс на узле сервера не находится в ожидании подключения к указанному нами порту (например, нужный процесс может быть не запущен). Это устойчивая неисправность ( hard error ), и клиенту возвращается сообщение ECONNREFUSED
сразу же по получении им сегмента RST.
RST (от «reset» — сброс) — это сегмент TCP, отправляемый собеседнику при возникновении ошибок. Вот три условия, при которых генерируется RST: сегмент SYN приходит для порта, не имеющего прослушивающего сервера (что мы только что описали); TCP хочет разорвать существующее соединение; TCP получает сегмент для несуществующего соединения (дополнительная информация содержится на с. 246–250 [111]).
3. Если сегмент SYN клиента приводит к получению сообщения ICMP о недоступности получателя от какого-либо промежуточного маршрутизатора, это считается случайным сбоем ( soft error ). Клиентское ядро сохраняет сообщение об ошибке, но продолжает отправлять сегменты SYN с теми же временными интервалами, что и в первом сценарии. Если же но истечении определенного фиксированного времени (75 с для 4.4BSD) ответ не получен, сохраненная ошибка ICMP возвращается процессу либо как EHOSTUNREACH
, либо как ENETUNREACH
. Может случиться, что удаленная система будет недоступна по любому маршруту из таблицы маршрутизации локального узла, или что возврат из connect
произойдет без всякого ожидания.
ПРИМЕЧАНИЕ
Многие более ранние системы, такие как 4.2BSD, некорректно прерывали попытки установления соединения при получении сообщения ICMP о недоступности получателя. Это было неверно, поскольку данная ошибка ICMP может указывать на временную неисправность. Например, может быть так, что эта ошибка вызвана проблемой маршрутизации, которая исправляется в течение 15 с.
Читать дальше
Конец ознакомительного отрывка
Купить книгу