19314 22038 pts/6 S ./tcpcli01 127.0.0.1 read_chan
Мы вызвали
ps
с несколько необычным набором аргументов для того, чтобы получить всю необходимую для дальнейшего обсуждения информацию. Мы запустили клиент и сервер из одного окна (
pts/6
, что означает псевдотерминал 6). В колонках
PID
и
PPID
показаны отношения между родительским и дочерним процессами. Можно точно сказать, что первая строка
tcpserv01
соответствует
родительскому процессу, а вторая строка
tcpserv01
— дочернему, поскольку PPID дочернего процесса — это PID родительского. Кроме того, PPID родительского процесса совпадает с PID интерпретатора команд (
bash
).
Колонка
STAT
для всех трех сетевых процессов отмечена символом
S
. Это означает, что процессы находятся в состоянии ожидания (sleeping). Если процесс находится в состоянии ожидания, колонка
WCHAN
сообщит нам о том, чем он занят. В Linux значение
wait_for_connect
выводится, если процесс блокируется функцией
accept
или
connect
, значение
tcp_data_wait
— если процесс блокируется при вводе или выводе через сокет, a
read_chan
— если процесс блокируется при терминальном вводе-выводе. Так что для наших трех сетевых процессов значения
WCHAN
выглядят вполне осмысленно.
5.7. Нормальное завершение
На этом этапе соединение установлено, и все, что бы мы ни вводили на стороне клиента, отражается обратно.
linux % tcpcli01 127.0.0.1эту строку мы показывали раньше
hello, worldнаш ввод
hello, world отраженная сервером строка
good bye
good bye
^DCtrl+D - наш завершающий символ для обозначения конца файла
Мы вводим две строки, каждая из них отражается, затем мы вводим символ конца файла (EOF)
Ctrl+D
, который завершает работу клиента. Если мы сразу же выполним команду
netstat
, то увидим следующее:
linux % netstat -а | grep 9877
tcp 0 0 *:9877 *:*
tcp 0 0 local host:42758 localhost:9877
Клиентская часть соединения (локальный порт 42 758) входит в состояние TIME_WAIT (см. раздел 2.6), и прослушивающий сервер все еще ждет подключения другого клиента. (В этот раз мы передаем вывод
netstat
программе
grep
, чтобы вывести только строки с заранее известным портом нашего сервера. Но при этом также удаляется строка заголовка.)
Перечислим этапы нормального завершения работы нашего клиента и сервера.
1. Когда мы набираем символ EOF, функция
fgets
возвращает пустой указатель, и функция
str_cli
возвращает
управление (см. листинг 5.4).
2. Когда функция
str_cli
возвращает управление клиентской функции
main
(см. листинг 5.3), последняя завершает работу, вызывая функцию
exit
.
3. При завершении процесса выполняется закрытие всех открытых дескрипторов, так что клиентский сокет закрывается ядром. При этом серверу посылается сегмент FIN, на который TCP сервера отвечает сегментом ACK. Это первая половина последовательности завершения работы соединения TCP. На этом этапе сокет сервера находится в состоянии CLOSE_WAIT, а клиентский сокет — в состоянии FIN_WAIT_2 (см. рис. 2.4 и 2.5).
4. Когда TCP сервера получает сегмент FIN, дочерний процесс сервера находится в состоянии ожидания в вызове функции
read
(см. листинг 5.2), а затем функция
read
возвращает нуль. Это заставляет функцию
str_echo
вернуть управление функции
main
дочернего процесса сервера.
5. Дочерний процесс сервера завершается с помощью вызова функции
exit
(см. листинг 5.1).
6. Все открытые дескрипторы в дочернем процессе сервера закрываются. Закрытие присоединенного сокета дочерним процессом вызывает отправку двух последних сегментов завершения соединения TCP: FIN от сервера клиенту и ACK от клиента (см. рис. 2.5). На этом этапе соединение полностью завершается. Клиентский сокет входит в состояние TIME_WAIT.
7. Другая часть завершения процесса относится к сигналу
SIGCHLD
. Он отправляется родительскому процессу, когда завершается дочерний процесс. Это происходит и в нашем примере, но мы не перехватываем данный сигнал в коде, и по умолчанию он игнорируется. Дочерний процесс входит в состояние зомби (zombie). Мы можем проверить это с помощью команды
ps
.
linux % ps -t pts/6 -o pid,ppid,tty,stat,args,wchan
PID PPID TT STAT COMMAND WCHAN
22038 22036 pts/6 S -bash read_chan
17870 22038 pts/6 S ./tcpserv01 wait_for_connect
19315 17870 pts/6 Z [tcpserv01 <defu do_exit
Теперь дочерний процесс находится в состоянии
Z
(зомби).
Процессы-зомби нужно своевременно удалять, а это требует работы с сигналами Unix. Поэтому в следующем разделе мы сделаем обзор управления сигналами, а затем продолжим рассмотрение нашего примера.
5.8. Обработка сигналов POSIX
Сигнал— это уведомление процесса о том, что произошло некое событие. Иногда сигналы называют программными прерываниями( software interrupts). Подразумевается, что процесс не знает заранее о том, когда придет сигнал.
Сигналы могут посылаться в следующих направлениях:
одним процессом другому процессу (или самому себе);
ядром процессу.
Сигнал
SIGCHLD
, упомянутый в конце предыдущего раздела, ядро посылает родительскому процессу при завершении дочернего.