5.6. Нормальный запуск

Наш небольшой пример использования TCP (около 150 строк кода для двух функций

, , , и ) позволяет понять, как запускаются и завершаются клиент и сервер и, что наиболее важно, как развиваются события, если произошел сбой на узле клиента или в клиентском процессе, потеряна связь в сети и т.д. Только при понимании этих «граничных условий» и их взаимодействия с протоколами TCP/IP мы сможем обеспечить устойчивость клиентов и серверов, которые смогут справляться с подобными ситуациями.

Сначала мы запускаем сервер в фоновом режиме на узле

.

Когда сервер запускается, он вызывает функции

, , и , а затем блокируется в вызове функции . (Мы еще не запустили клиент.) Перед тем, как запустить клиент, мы запускаем программу , чтобы проверить состояние прослушиваемого сокета сервера.

Здесь мы показываем только первую строку вывода и интересующую нас строку. Эта команда показывает состояние всех сокетов в системе, поэтому вывод может быть большим. Для просмотра прослушиваемых сокетов следует указать параметр

.

Результат совпадает с нашими ожиданиями. Сокет находится в состоянии LISTEN, локальный IP-адрес задан с помощью символа подстановки (то есть является универсальным) и указан локальный порт 9877. Функция

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

Затем на том же узле мы запускаем клиент, задав IP-адрес сервера 127.0.0.1. Мы могли бы задать здесь и нормальный адрес сервера (его IP-адрес в сети).

Клиент вызывает функции

и , последняя осуществляет трехэтапное рукопожатие TCP. Когда рукопожатие TCP завершается, функция connect возвращает управление процессу-клиенту, а функция — процессу-серверу. Соединение установлено. Затем выполняются следующие шаги:

1. Клиент вызывает функцию

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

2. Когда функция

возвращает управление процессу-серверу, последний вызывает функцию , а дочерний процесс вызывает функцию . Та вызывает функцию , блокируемую в ожидании получения данных от клиента.

3. Родительский процесс сервера снова вызывает функцию

и блокируется в ожидании подключения следующего клиента.

У нас имеется три процесса, и все они находятся в состоянии ожидания (блокированы): клиент, родительский процесс сервера и дочерний процесс сервера.

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

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

l

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

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

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

:

Мы вызвали

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

Колонка

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