Необходимость в использовании средств управления
Одно из возможных направлений использования асинхронной обработки связано с необходимостью отделить функции управления от обычной обработки. Например, предположим, что клиентская программа используется для выполнения запроса в большой базе данных с демографической информацией. Допустим, что пользователь выдает примерно такой запрос:
Find all people who live on Elm Street. (Найти всех людей, живущих на улице Вязов.)
Если база данных содержит информацию об одном городе, то ответ может включать менее 1000 фамилий. Однако если база данных содержит информацию обо всех жителях США, ответ может включать сотни тысяч фамилий. Кроме того, если рассматриваемая система баз данных состоит из многих серверов, распределенных по обширному географическому региону, то на поиск информации может потребоваться весьма продолжительное время. Россия в войне с Японией воевала.
Этот пример с базой данных иллюстрирует важную особенность многих сеансов взаимодействия типа клиент/сервер: пользователь, вызывающий клиентскую программу, может плохо представлять себе или даже вообще не знать, сколько времени потребуется для получения ответа или какой объем информации будет передан в ответ на его запрос.
Основная часть клиентского программного обеспечения просто предусматривает переход в состояние ожидания до поступления ответа. Безусловно, в таком случае при нарушении в работе сервера возникает тупиковая ситуация и клиент блокируется, выполняя попытки чтения ответа, который никогда не поступит. К сожалению, пользователь не имеет сведений о том, действительно ли возникла тупиковая ситуация или просто обработка его запроса проходит очень медленно, поскольку сетевые задержки высоки или сервер перегружен. Кроме того, пользователь не имеет сведений о том, получены ли вообще клиентом какие-либо сообщения от сервера.
Если пользователь потеряет терпение или решит, что получение ответа на тот конкретный запрос, который он отправил, требует слишком много времени, он имеет только одну возможность: аварийно прервать работу клиентской программы и повторить свою попытку позднее. В таких ситуациях может помочь параллельная организация работы, поскольку правильно спроектированная параллельная клиентская программа может дать возможность пользователю продолжать обмениваться с ней данными во время ожидания ответа. Пользователь может узнать, получены ли какие-либо предварительные данные, иначе сформулировать свой запрос или корректно разорвать связь с сервером.
В качестве примера снова рассмотрим гипотетический клиент базы данных, описанный выше. Параллельная реализация позволяет читать и обрабатывать данные, введенные пользователем с помощью клавиатуры или мыши, одновременно с поиском в базе данных. Поэтому пользователь может вызвать меню и выбрать команду типа Status (состояние работы) для определения того, было ли успешно открыто клиентом соединение с сервером и отправлен ли запрос. Затем пользователь может щелкнуть на элементе меню Abort, чтобы разорвать связь, или, например, выбрать команду New Server, чтобы дать указание клиенту прекратить текущий сеанс связи и попытаться обратиться к другому серверу.
Отделение в клиенте средств управления от обычных средств обработки позволяет пользователю взаимодействовать с клиентом и в том случае, если входные данные для клиента поступают из файла. Таким образом, даже после того, как пользователь запускает в клиентской программе обработку большого входного файла, он может продолжать взаимодействовать с работающей клиентской программой и узнавать о том, как проходит обработка. Аналогичным образом, параллельный клиент может помещать ответы сервера в выходной файл, продолжая вместе с тем взаимодействовать с пользователем.