Эквивалент этого параметра можно также применять к индивидуальным дейтаграммам, используя флаг MSG_DONTROUTE
с функциями send
, sendto
или sendmsg
.
Этот параметр часто используется демонами маршрутизации ( routed
и gated
) для того, чтобы миновать таблицу маршрутизации (в случае, если таблица маршрутизации неверна) и заставить пакет отправиться на определенный интерфейс.
Когда на сокете происходит ошибка, модуль протокола в ядре, происходящем от Беркли, присваивает переменной so_error
для этого сокета одно из стандартных значений Unix E xxx
. Это так называемая ошибка, требующая обработки ( pending error ) для данного сокета. Процесс может быть немедленно оповещен об ошибке одним из двух способов:
1. Если процесс блокируется в вызове функции select
(см. раздел 6.3), ожидая готовности данного сокета к чтению или записи, функция select
возвращает управление и уведомляет процесс о соответствующем состоянии готовности.
2. Если процесс использует управляемый сигналом ввод-вывод (см. главу 25), для него или для группы таких процессов генерируется сигнал SIGIO
.
Процесс может получить значение переменной so_error
, указав параметр сокета SO_ERROR
. Целое значение, возвращаемое функцией getsockopt
, является кодом ошибки, требующей обработки. Затем значение переменной so_error
сбрасывается ядром в 0 [128, с. 547].
Если процесс вызывает функцию read
и возвращаемых данных нет, а значение so_error
ненулевое, то функция read
возвращает -1 с errno
, которой присвоено значение переменной so_error
[128, с. 516]. Это значение so_error
затем сбрасывается в 0. Если в очереди для сокета есть данные, эти данные возвращаются функцией read
вместо кода ошибки. Если значение so_error
ненулевое, то при вызове процессом функции write
возвращается -1 с errno
, равной значению переменной so_error
[128, с. 495], а значение so_error
сбрасывается в 0.
ПРИМЕЧАНИЕ
В коде, показанном на с. 495 [128], есть ошибка: so_error не сбрасывается в 0. Она была выявлена в реализации BSD/OS. Всегда, когда для сокета возвращается ошибка, требующая обработки, so_error должна быть сброшена в 0.
Здесь вы впервые встречаетесь с параметром сокета, который можно получить, но нельзя установить.
Параметр сокета SO_KEEPALIVE
Когда параметр SO_KEEPALIVE
установлен для сокета TCP и в течение двух часов не происходит обмена данными по сокету в любом направлении, TCP автоматически посылает собеседнику проверочное сообщение (keepalive probe). Это сообщение — сегмент TCP, на который собеседник должен ответить. Далее события могут развиваться по одному из трех сценариев.
1. Собеседник отвечает, присылая ожидаемый сегмент ACK. Приложение не получает уведомления (поскольку все в порядке). TCP снова отправит одно проверочное сообщение еще через два часа отсутствия активности в этом соединении.
2. Собеседник отвечает, присылая сегмент RST, который сообщает локальному TCP, что узел собеседника вышел из строя и перезагрузился. Ошибка сокета, требующая обработки, устанавливается равной ECONNRESET
и сокет закрывается.
3. На проверочное сообщение не приходит ответ от собеседника. Код TCP, происходящий от Беркли, отправляет восемь дополнительных проверочных сообщений с интервалом в 75 с, пытаясь выявить ошибку. TCP прекратит попытки, если ответа не последует в течение 11 мин и 15 с после отправки первого сообщения.
ПРИМЕЧАНИЕ
HP-UX обрабатывает поверочные сообщения так же, как и обычные данные, то есть второе сообщение отсылается по истечении периода повторной передачи, после чего для каждого последующего пакета интервал ожидания удваивается, пока не будет достигнут максимальный интервал (по умолчанию — 10 мин).
Если на все проверочные сообщения TCP не приходит ответа, то ошибка сокета, требующая обработки, устанавливается в ETIMEDOUT
и сокет закрывается. Но если сокет получает ошибку ICMP (Internet Control Message Protocol — протокол управляющих сообщений Интернета) в ответ на одно из проверочных сообщений, то возвращается одна из соответствующих ошибок (см. табл. А.5 и А.6), но сокет также закрывается. Типичная ошибка ICMP в этом сценарии — Host unreachable
(Узел недоступен) — указывает на то, что узел собеседника не вышел из строя, а только является недоступным. При этом ошибка, ожидающая обработки, устанавливается в EHOSTUNREACH
. Это может произойти из-за отказа сети или при выходе удаленного узла из строя и обнаружении этого последним маршрутизатором.
Читать дальше
Конец ознакомительного отрывка
Купить книгу