14.1. Если не установлен обработчик, первый вызов функции

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

14.3. Приведем цикл

:

14.4. Данные продолжают выводиться, поскольку выход из функции

— это то же самое, что и возврат из этой функции. Функция вызывается программой запуска на языке С следующим образом:

Следовательно, вызывается функция

, а затем и программа очистки стандартного ввода-вывода.

15.1. Функция

удаляет имя файла из файловой системы, и когда клиент позже вызовет функцию , она не выполнится. Это не влияет на прослушиваемый сокет сервера, но клиенты не смогут выполнить функции после вызова функции .

15.2. Клиент не сможет соединиться с сервером с помощью функции

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

15.3. При выводе адреса протокола клиента путем вызова функции

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

Одним из решений является проверить доменный сокет Unix в функциях

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

15.4. Даже если мы заставим сервер вернуть в функции

1 байт на его 26- байтовый ответ, использование функции на стороне клиента гарантирует, что все 26 сегментов будут получены до вызова функции , в результате чего функция вернет полный ответ. Это еще одно подтверждение того, что TCP является потоком байтов с отсутствием границ записей.

Чтобы использовать доменные протоколы Unix, запускаем клиент и сервер с двумя аргументами командной строки

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

Поскольку для каждой функции

сервер определяет флаг , каждый байт рассматривается как логическая запись, и функция при каждом вызове возвращает 1 байт. Причина в том, что Беркли-реализации поддерживают флаг по умолчанию. Однако этот факт не документирован и не может использоваться в серийном коде. В данном примере мы используем эту особенность, чтобы показать разницу между потоком байтов и ориентированным на записи протоколом. С точки зрения реализации, каждая операция вывода идет в (буфер памяти) и флаг сохраняется ядром вместе с , когда переходит из отправляющего сокета в приемный буфер принимающего сокета. Когда вызывается функция read, флаг все еще присоединен к каждому , так что основная подпрограмма ядра (поддерживающая флаг , поскольку некоторые протоколы используют этот флаг) сама возвращает каждый байт. Если бы вместо мы использовали , флаг возвращался бы в поле каждый раз, когда возвращала бы 1 байт. Такой подход в TCP не срабатывает, поскольку отправляющий TCP не анализирует флаг в отсылаемом и в любом случае у нас нет возможности передать этот флаг принимающему TCP в TCP-заголовке. (Выражаем благодарность Мату Томасу (Matt Thomas) за то, что он указал нам это недокументированное «средство».)

15.5. В листинге Д.7 приведена реализация данной программы.

Листинг Д.7. Определение фактического количества собранных в очередь соединений для различных значений аргумента backlog