7.12. Родительский процесс сервера в листинге 5.1 большую часть времени блокирован в вызове функции

, а дочерний процесс в листинге 5.2 большую часть времени блокирован в вызове функции , который содержится в функции . Проверка работоспособности с помощью параметра не влияет на прослушиваемый сокет, поэтому в случае, если клиентский узел выйдет из строя, родительский процесс не пострадает. Функция read дочернего процесса возвратит ошибку примерно через 2 ч после последнего обмена данными через соединение.

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

, который, в свою очередь, блокирован операцией чтения из стандартной библиотеки ввода-вывода на стандартном устройстве ввода. Когда примерно через 2 ч после последнего обмена данными через соединение истечет время таймера проверки работоспособности и проверочные сообщения не выявят работоспособности сервера, ошибка сокета, ожидающая обработки, примет значение . Но клиент блокирован вызовом функции , поэтому он не увидит этой ошибки, пока не осуществит чтение или запись на сокете. Это одна из причин, по которой в главе 6 листинг 5.4 был изменен таким образом, чтобы использовать функцию .

7.14. Этот клиент большую часть времени блокирован вызовом функции

, которая сообщит, что сокет готов для чтения, как только ожидающая обработки ошибка будет установлена в (как показано в предыдущем решении).

7.15. Происходит обмен только двумя сегментами, а не четырьмя. Вероятность того, что таймеры двух систем будут строго синхронизированы, очень мала, следовательно, на одном конце соединения таймер проверки работоспособности сработает немного раньше, чем на другом. Первый из сработавших таймеров посылает проверочное сообщение, заставляя другой конец послать в ответ сегмент ACK. Но получение проверочного сообщения приводит к тому, что таймеру проверки работоспособности с более медленными часами будет присвоено новое значение — он сдвинется на 2 ч вперед.

7.16 Изначально в API сокетов не было функции

. Вместо этого четвертый аргумент функции содержал параметр сокета, а параметр использовался для задания прослушиваемого сокета. Когда добавилась функция , флаг остался, но теперь его может устанавливать только ядро [128, с. 456].

8.1. Да. Функция

возвращает 4096 байт данных, а функция возвращает 2048 байт (первую из двух дейтаграмм). Функция на сокете дейтаграмм никогда не возвращает больше одной дейтаграммы, независимо от того, сколько приложение запрашивает.

8.2. Если протокол использует структуры адреса сокета переменной длины,

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

8.4. Запуск программы

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

ПРИМЕЧАНИЕ

He все версии ping выводят сообщения об ICMP-ошибках, даже если задан параметр -v.

8.5. Прослушиваемый сокет может иметь приемный буфер определенного размера, но прослушиваемым TCP-сокетом данные никогда не принимаются. Большинство реализаций не выделяют заранее память под буферы отправки и приема. Размеры буферов сокета, определяемые параметрами

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

8.6. Запустим программу

с параметром (использовать UDP) и параметром (определяет локальный адрес и порт) на многоинтерфейсном узле .

Локальный IP-адрес подключен к Интернету (см. рис. 1.7), но чтобы достичь получателя, дейтаграмма должна выйти через другой интерфейс. Наблюдая за сетью с помощью программы

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