ПРИМЕЧАНИЕ

Мы специально поставили первым пунктом (после завершения трехэтапного рукопожатия) вызов функции str_cli, происходящий на стороне клиента, а затем уже перечислили действия на стороне сервера. Причину объясняет рис. 2.5: функция connect возвращает управление, когда клиент получает второй сегмент рукопожатия. Однако функция accept не возвращает управление до тех пор, пока сервер не получит третий сегмент рукопожатия, то есть пока не пройдет половина периода RTT после завершения функции connect.

Мы намеренно запускаем и клиент, и сервер на одном узле — так проще всего экспериментировать с клиент-серверными приложениями. Поскольку клиент и сервер запущены на одном узле, функция

отображает теперь две дополнительные строки вывода, соответствующие соединению TCP:

l

Первая из строк состояния

соответствует дочернему сокету сервера, поскольку локальным портом является порт 9877. Вторая строка — это клиентский сокет, поскольку локальный порт — порт 42 758. Если мы запускаем клиент и сервер на разных узлах, на узле клиента будет отображаться только клиентский сокет, а на узле сервера — два серверных сокета.

Для проверки состояний процессов и отношений между ними можно также использовать команду

:

Мы вызвали

с несколько необычным набором аргументов для того, чтобы получить всю необходимую для дальнейшего обсуждения информацию. Мы запустили клиент и сервер из одного окна ( , что означает псевдотерминал 6). В колонках и показаны отношения между родительским и дочерним процессами. Можно точно сказать, что первая строка соответствует родительскому процессу, а вторая строка — дочернему, поскольку PPID дочернего процесса — это PID родительского. Кроме того, PPID родительского процесса совпадает с PID интерпретатора команд ( ).

Колонка

для всех трех сетевых процессов отмечена символом . Это означает, что процессы находятся в состоянии ожидания (sleeping). Если процесс находится в состоянии ожидания, колонка сообщит нам о том, чем он занят. В Linux значение выводится, если процесс блокируется функцией или , значение — если процесс блокируется при вводе или выводе через сокет, a — если процесс блокируется при терминальном вводе-выводе. Так что для наших трех сетевых процессов значения выглядят вполне осмысленно.

На этом этапе соединение установлено, и все, что бы мы ни вводили на стороне клиента, отражается обратно.

Мы вводим две строки, каждая из них отражается, затем мы вводим символ конца файла (EOF)

, который завершает работу клиента. Если мы сразу же выполним команду , то увидим следующее: