СПОСОБ И СИСТЕМА ВЫПОЛНЕНИЯ УСЛУГ НА СЕРВЕРЕ И КЛИЕНТЕ КЛИЕНТ-СЕРВЕРНОЙ АРХИТЕКТУРЫ
METHOD AND SYSTEM FOR EXECUTING SERVICES ON SERVER AND CLIENT OF CLIENT-SERVER ARCHITECTURE

Область техники, к которой относится изобретение
Настоящее изобретение имеет отношение к технологии межпроцессного взаимодействия в области связи и компьютерного программного обеспечения и, в частности, к способу и системе выполнения услуг на сервере и клиенте клиент-серверной (C/S) архитектуры.
Уровень техники
С/S-архитектура представляет собой хорошо известную архитектуру клиента и сервера, которая является структурой систем программного обеспечения.
В целом, в С/S-архитектуре способ выполнения услуг на сервере и клиенте заключается в том, что: после запуска сервер должен подождать некоторое время, чтобы ответить на запрос на выполнение услуги, отправленный от клиента; клиент отвечает за отображение интерфейса и взаимодействие с пользователем. Когда пользователю необходимо отправить на сервер запрос с инструкцией на выполнение услуг, клиент отправляет на сервер запрос на выполнение услуг в соответствии с пользовательским запросом и ожидает приема информации о процессе выполнения или информации о результате выполнения, отправляемой от сервера. В задачи сервера входит: прием и выполнение запроса на выполнение услуг, отправленного от клиента, выполнение услуг в соответствии с запросом на выполнение услуг и возвращение результата выполнения услуг назад клиенту после того, как выполнение услуг будет завершено.
По большому счету, во время выполнения услуг в соответствии с принятым запросом на выполнение услуг клиент уже не может вмешиваться в процесс выполнения услуг на сервере. В общем случае это не оказывает никакого влияния на использование C/S-архитектуры для удовлетворения требований услуги со стороны клиента, однако есть одно исключение. Некоторые требования, предъявляемые к программному обеспечению, могут состоять в том, чтобы пользователь имел возможность вмешиваться в процесс выполнения услуг на сервере с помощью клиента. Например, надежды пользователя могут сводиться к принятию решения относительно действия или последовательности действий по выполнению услуг на сервере согласно различным ситуациям, возникающим после выполнения сервером услуг на определенной стадии.
Однако в настоящее время клиент не может управлять сервером во время выполнения услуг на сервере.
Раскрытие изобретения
Один аспект настоящего изобретения заключается в предоставлении способа и системы выполнения услуги на сервере и клиенте С/S-архитектуры, используемых для решения проблем, связанных с тем, что существующие технологии не позволяют пользователю вмешиваться или влиять на действие или последовательность действий по выполнению услуг на сервере, используя клиент в С/S-архитектуре.
Таким образом, согласно одному аспекту настоящего изобретения, предоставлен способ выполнения услуг на сервере C/S-архитектуры, содержащий следующие этапы, на которых:
при выполнении в заранее заданной точке принятия пользовательского решения во время процесса выполнения услуг приостанавливают на сервере выполнение услуг и инициируют отправку запроса пользовательского решения клиенту, при этом запрос пользовательского решения включает в себя информацию, запрашивающую пользователя принимать решение в отношении действия по выполнению услуг после точки принятия пользовательского решения;
после приема информации о пользовательском решении, сформированной клиентом в ответ на запрос пользовательского решения, определяют действие по выполнению услуг, соответствующее принятой информации о пользовательском решении, на основании соответствующей связи между информацией о пользовательском решении и инструкцией по выполнению услуг, и выполняют услуги в соответствии с определенным действием по выполнению услуг.
Согласно другому аспекту предоставлен также способ выполнения услуг на клиенте С/S-архитектуры, содержащий следующие этапы, на которых:
принимают запрос на выполнение услуг от пользователя и отправляют его на сервер, запрашивая сервер инициировать выполнение услуг;
принимают информацию от сервера во время выполнения услуг, причем, если информация является запросом пользовательского решения, указывают пользователю о том, что необходимо принять решение, и ожидают пользовательского ответа на запрос пользовательского решения, при этом запрос пользовательского решения содержит информацию для запрашивания у пользователя решения в отношении последующего действия по выполнению услуг; и
принимают информацию о пользовательском решении, сформированную пользователем в ответ на запрос пользовательского решения, причем клиент отправляет информацию о пользовательском решении на сервер.
В соответствии с дополнительным аспектом предоставлена также система выполнения услуг на сервере и клиенте C/S-архитектуры, причем система содержит:
модуль выполнения услуг на клиенте, выполненный с возможностью: инициировать отправку запроса на выполнение услуг на сервер; при приеме запроса пользовательского решения от сервера указывать пользователю, что необходимо принять решение, и ожидать пользовательского ответа на запрос пользовательского решения; и отправлять на сервер информацию о пользовательском решении, сформированную пользователем в ответ на запрос пользовательского решения;
модуль выполнения услуг на сервере, выполненный с возможностью: начинать выполнение услуг после приема запроса на выполнение услуг от клиента; при выполнении в заранее заданной точке принятия пользовательского решения во время выполнения услуг приостанавливать выполнение услуг и инициировать отправку запроса пользовательского решения клиенту; после приема информации о пользовательском решении, сформированной клиентом в ответ на запрос пользовательского решения, определять действие по выполнению услуг после точки принятия пользовательского решения в соответствии с информацией о пользовательском решении.
Благодаря настоящему изобретению, задавая точку принятия пользовательского решения во время последовательности действий по выполнению услуг на сервере, пользователь может принимать решения в точке принятия пользовательского решения и изменять последующее действие или последовательность действий по выполнению услуг в соответствии с принятыми решениями. Цель состоит в том, чтобы позволить клиенту вмешиваться или влиять на действие или последовательность действий по выполнению услуг на сервере.
Краткое описание чертежей
Фиг.1 иллюстрирует схему последовательности операций способа выполнения услуг на сервере C/S-архитектуры в соответствии с вариантом осуществления настоящего изобретения;
Фиг.2 иллюстрирует схему последовательности операции способа выполнения услуг на клиенте С/S-архитектуры в соответствии с вариантом осуществления настоящего изобретения;
Фиг.3 иллюстрирует структурную схему модуля выполнения услуг на сервере в первом варианте осуществления настоящего изобретения;
Фиг.4 иллюстрирует структурную схему модуля выполнения услуг на клиенте в первом варианте осуществления настоящего изобретения;
Фиг.5 иллюстрирует схему последовательности операций способа выполнения услуг на клиенте С/S-архитектуры во втором варианте осуществления настоящего изобретения; и
Фиг.6 иллюстрирует схему последовательности операций способа выполнения услуг на сервере С/S-архитектуры во втором варианте осуществления настоящего изобретения.
Осуществление изобретения
Настоящее изобретение будет далее описано более подробно в сочетании с чертежами и вариантами осуществления. Следует упомянуть, что варианты осуществления настоящего изобретения и его признаки могут быть объединены друг с другом, если это не вызывает противоречий.
Способ выполнения услуги на сервере C/S-архитектуры, обеспеченный вариантом осуществления настоящего изобретения, как показано на Фиг.1, содержит следующие этапы: этап S101, на котором при выполнении в заранее заданной точке принятия пользовательского решения во время выполнения услуги приостанавливают на сервере выполнение услуги и инициируют отправку запроса пользовательского решения клиенту, при этом запрос пользовательского решения содержит информацию для запрашивания у пользователя решения в отношении действия по выполнению услуги после точки принятия пользовательского решения; этап S102, на котором после приема информации о пользовательском решении, сформированной клиентом в ответ на запрос пользовательского решения, определяют действие по выполнению услуги, соответствующее принятой информации о пользовательском решении, на основании соответствующей связи между информацией о пользовательском решении и инструкцией по выполнению услуги, и выполняют услугу в соответствии с определенным действием по выполнению услуги.
Фиг.2 иллюстрирует способ выполнения услуги на клиенте C/S-архитектуры, обеспеченный вариантом осуществления настоящего изобретения, который содержит следующие этапы: этап S201, на котором принимают от пользователя запрос на выполнение услуги и отправляют его на сервер, запрашивая сервер начинать выполнение услуги; этап S202, на котором принимают информацию от сервера во время выполнения услуги, причем, когда информация является запросом пользовательского решения, указывают пользователю, что необходимо принять решения, и ожидают от пользователя ответа на запрос пользовательского решения, при этом запрос пользовательского решения содержит информацию для запрашивания у пользователя решения в отношении последующего действия по выполнению услуги; этап S203, на котором клиент принимает информацию о пользовательском решении, сформированную пользователем в ответ на запрос пользовательского решения, и отправляет информацию о пользовательском решении на сервер. Конфигурируя С/S-архитектуру, предпочтительные пользовательские требования, отправляемые клиентом, фактически инициируют отправку запроса на выполнение услуги на сервер. После запуска сервер использует цикл событий, чтобы отслеживать информацию от клиента, и начинает выполнять услугу, когда информация является запросом на выполнение услуги, а затем возвращает клиенту информацию о статусе выполнения услуги во время выполнения услуги от начала до конца. Когда информация о статусе выполнения услуги принимается клиентом от сервера, она выводится пользователю через интерфейс.
Система выполнения услуги на сервере и клиенте C/S-архитектуры, обеспеченная вариантом осуществления настоящего изобретения, содержит: модуль выполнения услуги на клиенте, который выполнен с возможностью инициировать отправку запроса на выполнение услуги на сервер, указывать пользователю, что необходимо принять решения, и ожидать от пользователя ответа на запрос пользовательского решения, когда от сервера принимается запрос пользовательского решения, и отправлять на сервер информацию о пользовательском решении, сформированную пользователем в ответ на запрос пользовательского решения/модуль выполнения услуги на сервере, который выполнен с возможностью начинать выполнение услуги после приема от клиента запроса на выполнение услуги, приостанавливать выполнение услуги и инициировать отправку запроса пользовательского решения клиенту при выполнении в заранее заданной точке принятия пользовательского решения во время выполнения услуги, и после приема информации о пользовательском решении, сформированной клиентом в ответ на запрос пользовательского решения, определять действие по выполнению услуги после точки принятия пользовательского решения в соответствии с информацией о пользовательском решении.
Фиг.3 иллюстрирует структурную схему модуля выполнения услуги на сервере в настоящем варианте осуществления. Модуль выполнения услуги на сервере содержит следующие модули. Модуль 301 задания точки принятия решения выполнен с возможностью задавать точку принятия пользовательского решения, необходимую для того, чтобы пользователь принимал решения во время выполнения услуги на сервере. Модуль 302 инициации отправки запроса решения выполнен с возможностью приостанавливать выполнение услуги и инициировать отправку запроса пользовательского решения клиенту при выполнении в заранее заданной точке принятия пользовательского решения во время выполнения услуги на сервере, при этом запрос пользовательского решения содержит информацию для запрашивания у пользователя решения в отношении действия по выполнению услуги после точки принятия пользовательского решения. Модуль 303 выполнения реализован с возможностью определять после приема информации о пользовательском решении, сформированной клиентом в ответ на запрос пользовательского решения, действие по выполнению услуги, соответствующее принятой информации о пользовательском решении, на основании соответствующей связи между информацией о пользовательском решении и инструкцией по выполнению услуги и выполнять услугу в соответствии с определенным действием по выполнению услуги. Фиг.4 иллюстрирует структурную схему модуля выполнения услуги на клиенте в настоящем варианте осуществления, причем модуль выполнения услуги на клиенте содержит следующие модули. Модуль 401 запроса выполнения услуги выполнен с возможностью инициировать отправку запроса на выполнение услуги на сервер в соответствии с пользовательскими требованиями, который запрашивает сервер начинать выполнение услуги. Модуль 402 приема выполнен с возможностью принимать информацию от сервера во время выполнения услуги. Модуль 403 запроса решения выполнен с возможностью указывать пользователю, что необходимо принять решения, и ожидать от пользователя ответа на запрос пользовательского решения, когда принятая информация представляет собой запрос пользовательского решения. Модуль 404 отправки выполнен с возможностью отправлять на сервер информацию о пользовательском решении, получаемую после пользовательского ответа на запрос пользовательского решения.
Предпочтительно, чтобы точка принятия пользовательского решения могла быть задана сервером в соответствии с условием выполнения услуги или конфигурировалась клиентом. Режим, с помощью которого точка принятия пользовательского решения задается сервером в соответствии с условием выполнения услуги, имеет относительно высокую гибкость. Например, точка принятия пользовательского решения задается, когда обнаруживаются риски безопасности, существующие при выполнении услуги, при этом пользователю отправляется запрос принятия решения о том, выполнять ли последующую услугу или нет. Режим, при котором точка принятия пользовательского решения в последовательности действий по выполнению услуги конфигурируется клиентом, может лучше соответствовать пользовательским требованиям, но при этом обладать меньшей гибкостью. Запрос пользовательского решения может содержать информацию о различных маркировочных битах, которая запрашивает пользователя принимать решения, причем информация о различных маркировочных битах соответствует различным действиям по выполнению услуги в инструкции по выполнению услуги. Информация о пользовательском решении является информацией об одном из выбранных маркировочных битов. Соответственно сервер может принимать решения в отношении действия по выполнению услуги с помощью инструкции по выполнению услуги после точки принятия пользовательского решения в соответствии с принятой информацией о маркировочных битах и осуществлять действие по выполнению услуги. Разумеется, запрос пользовательского решения не ограничен вышеупомянутыми формами, он может иметь любую другую форму, которая передает пользователю запрос принятия решения в отношении последующего действия по выполнению услуги. Способ и система, обеспеченные вариантом осуществления настоящего изобретения, подходят для C/S-архитектуры. Вариант осуществления настоящего изобретения подходит для сетевой системы с С/S-архитектурой и системы программного обеспечения с С/S-архитектурой.
Согласно первому варианту осуществления настоящего изобретения, в способе выполнения услуги на клиенте и сервере С/S-архитектуры сервер и клиент конфигурируют различные типы информации в программе для отображения запроса на выполнение услуги, информации о пользовательском решении, информации о статусе выполнения услуги и запроса пользовательского решения.
Во время выполнения услуги клиентом и сервером сообщения, отправленные от клиента серверу, распределяются по классам, которые содержат следующие типы. A1 - сообщение с запросом на выполнение услуги, которое характеризует запрос на выполнение услуги, т.е. пользователь ожидает, что сервер выполнит определенный вид услуги. А2 - сообщение с пользовательским решением, которое характеризует информацию о пользовательском решении, т.е. пользовательский ответ на запрос пользовательского решения, отправленный от сервера.
Сообщения, отправленные от сервера клиенту, также распределяются по классам, которые содержат следующие типы. B1 - сообщение со статусом выполнения услуги, которое характеризует информацию о статусе выполнения услуги, т.е. характеризует ответную реакцию на результат выполнения услуги или промежуточную информацию от выполнения услуги сервером в соответствии с запросом на выполнение услуги, отправленным пользователем, которая может сообщать в ответ, выполнен ли пользовательский запрос на выполнение услуги успешно или нет, или указывать стадии его выполнения. Сообщение со статусом выполнения услуги может также быть классифицировано как сообщение-указание, сообщение-предупреждение, сообщение об ошибке, сообщение о ходе выполнения и ответное сообщение о событии, соответствующее разным запросам на выполнение услуги. В2 - сообщение с запросом пользовательского решения, которое характеризует запрос пользовательского решения, т.е. указывает пользователю, что необходимо принять решение в отношении последующего действия или последовательности действий по выполнению услуги, когда сервер осуществляет обработку в заранее заданной точке принятия пользовательского решения,
В настоящем варианте осуществления различные типы сообщений, описанные выше, передаются между клиентом и сервером по каналу сообщений, при этом канал сообщений может представлять собой сокет, программный канал, очередь сообщений или другое средство межпроцессного взаимодействия.
Так называемый сокет (также именуемый просто «сокет»), используемый для описания IP-адреса и порта, представляет собой контроллер линии связи. Приложение, как правило, отправляет запрос в сеть или отвечает на сетевой запрос с помощью «сокета». При этом клиент использует произвольный сокет, сетевая система распределяет клиенту определенное число сокетов (далее именуемых как клиентские сокеты), и сервер имеет сокет, подтвержденный во всей локальной сети (далее именуемый как серверный сокет), причем клиент может отправлять серверу запрос соединения и запрос информации. В частности, сервер использует серверный сокет для отслеживания заданного порта, при этом порт может быть задан произвольным образом, ожидает запроса соединения от клиента, создает сеанс после соединения с клиентом и завершает соединение после окончания сеанса. Клиент использует клиентский сокет для отправки запроса соединения на порт сервера в сети, открывает сеанс в случае успешного соединения и закрывает клиентский сокет после окончания сеанса.
Программный канал используется в качестве области совместно используемой памяти в межпроцессном взаимодействии. Один процесс записывает информацию в программный канал, а другой процесс считывает информацию из программного канала.
Сообщение представляет собой блок данных, передаваемый между двумя компьютерами. Сообщение отправляется согласно очереди. Очередь сообщений представляет собой хранилище, в котором хранятся сообщения во время процесса его передачи, при этом основная цель очереди сообщений заключается в том, чтобы обеспечить маршрутизацию и гарантировать передачу сообщения.
В настоящем варианте осуществления структура сообщения, отправляемая от клиента серверу, и структура сообщения, отправляемая от сервера клиенту, могут определяться независимо или могут быть объединены в одну структуру.
Сервер и клиент настоящего варианта осуществления используют цикл событий для отслеживания сообщения в программе. Клиент использует третий цикл событий для отслеживания сообщения, характеризующего запрос на выполнение услуги, и сообщения, характеризующего информацию о пользовательском решении, от пользователя, т.е. третий цикл событий отслеживает пользовательское событие в интерфейсе клиента. Четвертый цикл событий используется для отслеживания сообщения, характеризующего запрос пользовательского решения, и сообщения, характеризующего информацию о статусе выполнения услуги, от сервера, т.е. четвертый цикл событий используется для отслеживания канала сообщений. В настоящем варианте осуществления четвертый цикл событий, используемый клиентом для отслеживания канала сообщений, именуется CL1. Поскольку цикл событий клиента отслеживает пользовательское событие интерфейса и канал сообщений, при объединении третьего цикла событий и четвертого цикла событий настоящий вариант осуществления использует третий цикл событий как основной цикл событий и конфигурирует средство отслеживания побуждения событий, при этом четвертый цикл событий конфигурирует средство запроса синхронизации.
На сервере первый цикл событий используется для отслеживания сообщения, характеризующего запрос на выполнение услуги от клиента. В настоящем варианте осуществления отслеживание канала сообщений сервером обозначается как SL1. Согласно различным принятым сообщениям с запросом на выполнение услуги, сервер вызывает разные функции манипуляции и выполняет разные действия или последовательность действий по выполнению услуги. Второй цикл событий используется для отслеживания сообщения, характеризующего информацию о пользовательском решении от клиента, и это отслеживание сервером обозначается как SL2 в настоящем варианте осуществления. В способе выполнения услуги на сервере и клиенте C/S-архитектуры SL1 отслеживает канал сообщений между сервером и клиентом непрерывным и повторяемым способом. Сервер начинает выполнение услуги при отслеживании сообщения, характеризующего запрос на выполнение услуги. При выполнении в заранее заданной точке принятия пользовательского решения во время выполнения услуги, сервер обнаруживает, что пользователю необходимо принять решения, приостанавливает выполнение услуги и инициирует отправку клиенту сообщения с запросом пользовательского решения, и ожидает от клиента ответа на запрос пользовательского решения, в то же время сервер блокирует цикл событий SL1 и запускает цикл событий SL2 для отслеживания канала сообщений. После отслеживания клиентом сообщения с запросом пользовательского решения от сервера с помощью четвертого цикла событий, клиент высвечивает на экране интерфейс запроса и ожидает от пользователя ответа. Когда третий цикл событий клиента перехватывает пользовательский ответ (сообщение с пользовательским решением), клиент отправляет сообщение с пользовательским решением на сервер по каналу сообщений. После отслеживания циклом событий SL2 сервера сообщения с пользовательским решением, согласно информации о пользовательском решении, сервер выполняет соответствующую услугу по вышеупомянутым правилам, аннулирует цикл событий SL2 и завершает его, и восстанавливает цикл событий SL1. Сервер ожидает сообщение с запросом на выполнение услуги, отправленное от клиента.
В настоящем варианте осуществления цикл событий SL1 или SL2 сервера может, в принципе, принимать все сообщения, отправленные от клиента серверу по каналу сообщений. Однако в настоящем документе предусмотрено, чтобы цикл событий SL1 был предназначен только для приема сообщения с запросом на выполнение услуги. Если сообщение с пользовательским решением принимается посредством цикла событий SL1, оно немедленно отвергается. Цикл событий существует до окончания обработки на сервере. В настоящем варианте осуществления цикл событий SL2 предназначен только для приема сообщения с пользовательским решением. Если сообщение с запросом на выполнение услуги принимается посредством цикла событий SL2, оно сразу же отвергается. Цикл событий SL2 будет аннулирован и завершен после приема сервером сообщения с пользовательским решением.
Пользователь может вмешиваться или влиять на действие или последовательность действий по выполнению услуги на сервере с помощью клиента в соответствии со способом, раскрытым в настоящем варианте осуществления. Во время выполнения услуги в соответствии с запросом на выполнение услуги, при выполнении в заранее заданной точке принятия пользовательского решения, сервер отправляет сообщение с запросом пользовательского решения клиенту и одновременно запускает цикл событий в точке принятия пользовательского решения, отслеживает канал сообщений и ожидает сообщения с пользовательским решением, так что клиент может вмешиваться или влиять на действие или последовательность действий по выполнению услуги на сервере.
Вышеупомянутый способ настоящего варианта осуществления не ограничен платформой операционной системы или операционной средой, и он пригоден до тех пор, пока операционная система поддерживает межпроцессное взаимодействие. Способ также не ограничен С/3-архитектурой типа «один к одному» и, кроме того, подходит для расширяемой архитектуры типа «многие к одному», при которой сервер начинает различную обработку запросов на выполнение услуги от различных клиентов.
В соответствии со вторым вариантом осуществления настоящего изобретения в способе выполнения услуг клиентом и сервером в C/S-архитектуре, при выполнении услуги по установке пакетов программного обеспечения, например, в смартфоне на платформе Linux, все пакеты программного обеспечения помещаются на сетевой сервер с конфигурационным файлом, указывающим связанную с ними информацию о всех программных обеспечениях, включая название, номер версии, значение MD5 (алгоритм представления сообщения в краткой форме) и т.д. для программного обеспечения, а программа управления пакетами на терминале мобильного телефона будет загружать этот конфигурационный файл для получения всей информации о пакетах программного обеспечения. При этом программа управления пакетами на терминале мобильного телефона основана на С/S-архитектуре, графический интерфейс клиента основан на средстве разработки gtk+, сервер использует язык программирования С и сокет выбирается в качестве канала сообщений между клиентом и сервером. Клиент и сервер используют режим «один к одному», хотя специалистам в данной области техники должно быть понятно, что настоящее изобретение не ограничено выполнением услуг с помощью вышеупомянутых признаков, и C/S-архитектура не ограничена режимом «один к одному». Канал сообщений также не ограничен сокетом.
Упомянутый выше MD5, который используется для обеспечения передачи информации, наиболее широко применяется при подтверждении паролей и идентификации ключей всех видов программного обеспечения. В целом, упомянутые порядковые номера являются полными и постоянными. Как правило, информация о программном обеспечении на некоторых сайтах для загрузки программного обеспечения часто содержит значение MD5, функция которого заключается в том, чтобы проводить проверку MD5 загружаемого файла посредством использования специального программного обеспечения (например, проверка MD5 для Windows) после загрузки программного обеспечения, чтобы гарантировать, что полученный файл является файлом, предоставленным сайтом.
Как показано на Фиг.5, способ выполнения услуги на клиенте С/S-архитектуры настоящего варианта осуществления содержит следующие этапы (S501-S507).
Этап S501: Определение структуры сообщений, подходящей для передачи сообщений между клиентом и сервером.
В настоящем варианте осуществления сообщение, отправляемое от клиента серверу, и сообщение, отправляемое сервером клиенту, используют принцип идентичных структур, который представляет собой Message_t с программой в следующем виде:
typedef struct
{
Type_t type;
Context_t content;
} Message_t.
В данной структуре содержится две объектные переменные, при этом тип представляет собой перечисляемую переменную, указывающую класс сообщения, в частности характеризующую сообщение с запросом на выполнение услуги и сообщение с пользовательским решением, когда клиент отправляет сообщение серверу, и характеризующую сообщение с запросом пользовательского решения и сообщение со статусом выполнения услуги и т.д., когда сервер отправляет сообщение клиенту; и содержимое представляет собой структуру, указывающую подробности, содержащиеся в сообщении.
Этап S502: После запуска клиент создает сокетный канал, получает клиентский сокет client_sock и соединяет клиентский сокет client_sock с сервером, при этом создается канал сообщений между клиентом и сервером.
Этап S503: Определение третьего цикла событий для осуществления интерфейсного отслеживания, чтобы клиент мог получать пользовательское действие (т.е. захват сообщения с запросом на выполнение услуги и сообщения с пользовательским решением) посредством отслеживания третьего цикла событий интерфейса и отправлять его на сервер.
Этап S504: Клиент включает таймер, определяет и использует четвертый цикл событий, который использует способ считывания времени, чтобы осуществлять считывание данных на порту сокета, и отслеживает четвертый цикл событий канала сообщений, в частности, используя способ считывания времени, при этом пример кода выглядит следующим образом:
gtk_timeout_add (500, get_pending_message, NULL)
Функция get pending_message используется для считывания сообщения (включающего в себя сообщение с запросом пользовательского решения и сообщение со статусом выполнения услуги) на сокете, отправленном от сервера, вызова различной функции обработки в соответствии с классом сообщения, например, после отслеживания сообщения с запросом пользовательского решения, высвечивания на экране интерфейса, запрашивающего пользователя принимать решение, и при отслеживании сообщения со статусом выполнения услуги отправки этого сообщения пользователю через интерфейс.
Этап S505: На основании вышеупомянутых этапов, когда пользователь клиента имеет некоторые конкретные требования, сначала осуществляется перехват информации о запросе на выполнение услуги через третий цикл событий, а затем отправка информации о запросе на выполнение услуги сетевому серверу. На данном этапе сетевой сервер, выступающий в качестве сервера, и мобильный телефон, выступающий в качестве клиента, используют четвертый цикл событий для отслеживания канала сообщений. Для запроса на выполнение услуги, являющегося сообщением с запросом на установку в настоящем варианте осуществления, когда пользователь выбирает пакет программного обеспечения на мобильном телефоне и запрашивает сетевой сервер установить его, мобильный телефон отправляет сетевому серверу сообщение с запросом на установку. После приема этого запроса сетевой сервер загружает пакет программного обеспечения на локальное устройство (т.е. мобильный телефон) и начинает установку. Поскольку программа управления пакетами на терминале мобильного телефона основана на С/S-архитектуре, то во время установки пакета программного обеспечения пользовательский интерфейс является клиентом, а программа установки пакетов в фоновом режиме сервером.
Этап S506: После отслеживания четвертым циклом событий сообщения с запросом пользовательского решения происходит высвечивание на экране диалогового окна или текстуального интерфейса, запрашивающего пользователя принять решение, а после использования третьего цикла событий для получения сообщения с пользовательским решением осуществляется отправка сообщения с пользовательским решением на сервер.
Этап S507: После отслеживания четвертым циклом событий сообщения со статусом выполнения услуги осуществляется вывод этого сообщения пользователю через интерфейс, например, вывод пользователю результата выполнения услуги, который свидетельствует об успешной загрузке или неудачной загрузке.
Как показано на Фиг.6, способ выполнения услуги на сервере С/S-архитектуры согласно настоящему варианту осуществления содержит следующие этапы (S601-S608).
Этап S601: Определение структуры сообщений, подходящей для передачи сообщений между клиентом и сервером. В настоящем варианте осуществления сообщение, отправленное клиентом на сервер, и сообщение, отправленное сервером клиенту, используют принцип идентичных структур, который представляет собой Message_t, в частности, являющийся таким же, что и описанный выше на этапе S501.
Этап S602: После запуска сервер создает сокетный канал с именем, которое хорошо известно или может быть найдено клиентом.
Этап S603: Осуществление привязки и ожидание сокетного канала, созданного на этапе S602.
Этап S604: После отслеживания запроса на соединение от клиента получение идентификатора сокета server sock после соединения.
Этап S605: Определение использования цикла событий для отслеживания server_sock; в настоящем документе примерный код цикла событий реализован через цикл с проверкой условия (wait_message()), причем функция сообщения wait message используется для считывания сообщения по сокету от клиента и вызова различной функции обработки в соответствии с классом сообщения. В настоящем документе, в частности, осуществляется определение первого цикла событий для отслеживания сообщения с запросом на выполнение услуги от клиента и определение второго цикла событий для отслеживания сообщения с пользовательским решением от клиента.
Этап S606: На основании вышеупомянутых этапов, когда пользователь клиента имеет некоторые конкретные требования, сначала осуществляется перехват сообщения с запросом на выполнение услуги через первый цикл событий, а затем начинается выполнение услуги в соответствии с сообщением с запросом на выполнение услуги. Если мобильный телефон является клиентом, а сетевой сервер является сервером до установки пакета программного обеспечения, и после приема сообщения с запросом на установку от мобильного телефона, сетевой сервер начинает выполнение услуги по загрузке этого пакета программного обеспечения от сетевого сервера на локальное устройство и начинает установку после окончания загрузки. Поскольку программа управления пакетами на терминале мобильного телефона основана на C/S-архитектуре, то во время установки пакета программного обеспечения пользовательский интерфейс является клиентом, а программа установки пакетов в фоновом режиме - сервером.
Этап S607: Приостановление выполнения услуги при выполнении в точке принятия пользовательского решения, т.е. незапланированная остановка первого цикла событий, отправка запроса пользовательского решения клиенту и запуск второго цикла событий для отслеживания информации о пользовательском решении от клиента. Например, после загрузки пакета программного обеспечения от сетевого сервера на локальное устройство и начала установки программа установки пакетов в фоновом режиме, выступающая в качестве сервера, будет проверять, совпадает ли значение MD5 пакета программного обеспечения с таким же значением конфигурационного файла на сетевом сервере. Если имеет место совпадение, то это означает, что пакет не изменялся третьей стороной и, следовательно, может быть безопасно установлен; в противном случае несовпадение означает, что пакет программного обеспечения изменялся третьей стороной, и поэтому имеются риски безопасности. На данном этапе выполнение услуги на сервере требует от пользователя принятия решения, и сервер отправляет сообщение с запросом пользовательского решения клиенту, в то же время согласно настоящему документу сервер вызывает функцию wait message, запускает второй цикл событий и ожидает пользовательского ответа. Сервер в настоящем варианте осуществления проверяет безопасность установки пакета программного обеспечения в соответствии с условием выполнения услуги. Если имеются риски безопасности, сервер задает точку принятия пользовательского решения, чтобы приостановить услугу и запрашивает пользователя принять решение об установке. Если нет рисков, сервер не задает точку принятия пользовательского решения для приостановления услуги и сразу же проводит установку. Запрос пользовательского решения в настоящем варианте осуществления содержит информацию о двух разных маркировочных битах, которая запрашивает пользователя сделать выбор, при этом информация об одном из маркировочных битов соответствует действию по выполнению услуги, заключающемуся в продолжении установки пакета программного обеспечения, в инструкции по выполнению услуги, а информация о другом маркировочном бите соответствует действию по выполнению услуги, заключающемуся в невыполнении установки пакета программного обеспечения, в инструкции по выполнению услуги.
Этап S608: Когда второй цикл событий отслеживает данные о server sock, происходит считывание данных и преобразование их в структуру сообщения Message_t, и анализ содержимого сообщения для получения информации о пользовательском решении. Информация о пользовательском решении в настоящем варианте осуществления представляет собой информацию о выбранном маркировочном бите. Сервер определяет последующее действие по выполнению услуги в соответствии с принятым пользовательским решением, завершает второй цикл событий и возвращается снова к первому циклу событий. На этом завершается последовательность действий, с помощью которой клиент может вмешиваться в выполнение услуги на сервере. Когда клиенту требуется снова вмешаться в выполнение услуги на сервере, этапы S607 и S608 повторяются.
Во время выполнения услуги сервер может возвращать клиенту информацию о статусе выполнения услуги.
Очевидно, что специалисты в данной области техники могут осуществить различные модификации и изменения настоящего изобретения, не отходя от сущности и объема настоящего изобретения. Таким образом, если эти модификации и изменения настоящего изобретения входят в объем формулы изобретения и другие технические знания, подразумевается, что настоящее изобретение включает в себя такие модификации и изменения.