4. В нашем примере в разделе 5.12 мы проверили, что первые два сегмента завершения соединения (сегмент FIN от сервера, на который затем клиент отвечает сегментом ACK) отправляются, при просмотре состояний сокета с помощью программы
netstat
. Происходит ли обмен двумя последними сегментами (FIN от клиента, на который затем сервер отвечает сегментом ACK)? Если да, то когда? Если нет, то почему?
5. Что произойдет с примером, рассмотренным в разделе 5.14, если между шагами 2 и 3 мы перезапустим сервер на узле сервера?
6. Чтобы проверить, что происходит с сигналом
SIGPIPE
в разделе 5.13, измените листинг 5.3 следующим образом. Напишите обработчик сигнала для
SIGPIPE
, который будет просто выводить сообщение и возвращать управление. Установите этот обработчик сигнала перед вызовом функции
connect
. Измените номер порта сервера на 13 (порт сервера времени и даты). Когда соединение установится, с помощью функции
sleep
войдите в состояние ожидания на 2 с, с помощью функции
write
запишите несколько байтов в сокет, проведите в состоянии ожидания (
sleep
) еще 2 с и с помощью функции
write
запишите еще несколько байтов. Запустите программу. Что происходит?
7. Что произойдет на рис. 5.5, если IP-адрес узла сервера, заданный клиентом при вызове функции
connect
, является IP-адресом, связанным с крайним правым канальным уровнем на стороне сервера, а не IP-адресом, связанным с крайним левым канальным уровнем?
8. В нашем примере эхо-сервера, осуществляющего сложение двух целых чисел (см. листинг 5.14), когда клиент и сервер принадлежат системам с различным порядком байтов, для небольших положительных чисел получается правильный ответ, но для небольших отрицательных чисел ответ неверен. Почему? (
9. В нашем примере в листинге 5.13 и 5.14 можем ли мы решить проблему, связанную с различным порядком байтов на стороне клиента и на стороне сервера, если клиент преобразует два аргумента в сетевой порядок байтов, используя функцию
htonl
, а сервер затем вызывает функцию
ntohl
для каждого аргумента перед сложением и выполняет аналогичное преобразование результата?
10. Что произойдет в листинге 5.13 и 5.14, если в качестве узла клиента используется компьютер SPARC, где данные типа
long
занимают 32 бита, а в качестве узла сервера — Digital Alpha, где данные типа
long
занимают 64 бита? Изменится ли что-либо, если клиент и сервер поменяются местами?
11. На рис. 5.5 указано, что IP-адрес клиента выбирается IP на основе маршрутизации. Что это значит?
Глава 6
Мультиплексирование ввода-вывода: функции select и poll
6.1. Введение
В разделе 5.12 мы видели, что наш TCP-клиент обрабатывает два входных потока одновременно: стандартный поток ввода и сокет TCP. Проблема, с которой мы столкнулись, состояла в том, что пока клиент был блокирован в вызове функции
fgets
(чтение из стандартного потока ввода), процесс сервера мог быть уничтожен. TCP сервера корректно отправляет сегмент FIN протоколу TCP клиента, но поскольку процесс клиента блокирован при чтении из стандартного потока ввода, он не получит признак конца файла, пока не считает данные из сокета (возможно, значительно позже). Нам нужна возможность сообщить ядру, что мы хотим получить уведомления о том, что выполняется одно или несколько условий для ввода-вывода (например, присутствуют данные для считывания или дескриптор готов к записи новых данных). Эта возможность называется
select
и
poll
. Мы рассмотрим также более новый вариант функции
select
, входящей в стандарт POSIX, называемый
pselect
.
В некоторых системах предоставляются более мощные средства ожидания событий. Одним из механизмов является устройство опроса (poll device), которое по-разному реализуется разными производителями. Этот механизм описывается в главе 14.
Мультиплексирование ввода-вывода обычно используется сетевыми приложениями в следующих случаях:
Когда клиент обрабатывает множество дескрипторов (обычно интерактивный ввод и сетевой сокет), должно использоваться мультиплексирование ввода- вывода. Это сценарий, который мы только что рассмотрели.
Возможно, хотя это и редкий случай, что клиент одновременно обрабатывает множество сокетов. Такой пример мы приведем в разделе 16.5 при использовании функции
select
в контексте веб-клиента.
Если сервер TCP обрабатывает и прослушиваемый сокет, и присоединенные сокеты, обычно используется мультиплексирование ввода-вывода, как это показано в разделе 6.8.