У нас имеется три процесса, и все они находятся в состоянии ожидания (блокированы): клиент, родительский процесс сервера и дочерний процесс сервера.
ПРИМЕЧАНИЕ
Мы специально поставили первым пунктом (после завершения трехэтапного рукопожатия) вызов функции str_cli, происходящий на стороне клиента, а затем уже перечислили действия на стороне сервера. Причину объясняет рис. 2.5: функция connect возвращает управление, когда клиент получает второй сегмент рукопожатия. Однако функция accept не возвращает управление до тех пор, пока сервер не получит третий сегмент рукопожатия, то есть пока не пройдет половина периода RTT после завершения функции connect.
Мы намеренно запускаем и клиент, и сервер на одном узле — так проще всего экспериментировать с клиент-серверными приложениями. Поскольку клиент и сервер запущены на одном узле, функция netstat
отображает теперь две дополнительные строки вывода, соответствующие соединению TCP:
l inux % netstat -a
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:9877 localhost:42758 ESTABLISHED
tcp 0 0 localhost:42758 localhost:42758 ESTABLISHED
tcp 0 0 *:9877 *:* LISTEN
Первая из строк состояния ESTABLISHED
соответствует дочернему сокету сервера, поскольку локальным портом является порт 9877. Вторая строка ESTABLISHED
— это клиентский сокет, поскольку локальный порт — порт 42 758. Если мы запускаем клиент и сервер на разных узлах, на узле клиента будет отображаться только клиентский сокет, а на узле сервера — два серверных сокета.
Для проверки состояний процессов и отношений между ними можно также использовать команду 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 wait4
17870 22038 pts/6 S ./tcpserv01 wait_for_connect
19315 17870 pts/6 S ./tcpserv01 tcp_data_wait
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
^D Ctrl+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
.
Читать дальше
Конец ознакомительного отрывка
Купить книгу