Однопотоковые реализации

В тех случаях, если система не поддерживает разделяемую память или создание дополнительных потоков считается нежелательным, параллельная организация работы клиента может быть осуществлена с помощью однопотокового алгоритма, аналогичного алгоритму 8.5 и показанного на примерах в главах 13-15. Такая схема организации процессов приведена на рис. 17.2. В клиентской программе для одновременной поддержки нескольких соединений используется функция select.

В однопотоковом клиенте, как и в однопотоковом сервере, используется асинхронный ввод/вывод. Клиент создает дескрипторы сокетов для соединений TCP с несколькими серверами. В нем может также дополнительно контролироваться один или несколько дескрипторов файлов, через которые поступают данные, введенные с помощью клавиатуры или мыши. Тело клиентской программы состоит из цикла, в котором вызывается функция select для перехода к ожиданию состояния готовности одного из дескрипторов. Если готов дескриптор ввода, клиент считывает введенные данные и либо сохраняет их для дальнейшего использования, либо немедленно на них реагирует. Если же готов для вывода сокет TCP, клиент формирует и передает запрос через соединение TCP. А если этот сокет готов для ввода, клиент считывает и обрабатывает ответ, полученный с сервера.

Безусловно, однопотоковый параллельный клиент во многом характеризуется такими же преимуществами и недостатками, как и однопотоковая версия сервера. Клиент успешно читает входные данные или ответы сервера независимо от того, с какой скоростью они вырабатываются. Локальная обработка продолжается, даже если сервер на короткое время замедляет свою работу, поэтому клиент продолжает читать и выполнять команды управления, даже если сервер больше не в состоянии отвечать на запросы.

Однопотоковый клиент может оказаться в тупиковой ситуации, если в нем произойдет вызов системной функции, которая заблокируется. Поэтому в процессе разработки клиентской программы необходимо следить за тем, чтобы в ней не происходила блокировка на неопределенно долгое время в ожидании события, которое никогда не произойдет. Безусловно, иногда разработчики такую возможность развития событий игнорируют и возлагают задачу определения тупиковой ситуации на пользователя. Поэтому важно понимать все эти тонкости и уметь принимать продуманные решения по устранению каждой из возможных тупиковых ситуаций.