[susanin]

Сейчас в клиент-серверном варианте взаимодействие происходит по синхронному приципу: клиент посылает запрос (может физически выполняться на сервере), получает результат и обрабатывает его. В управляемом приложении это выполняет сервер (если приложение правильно написано) и передает клиенту готовую форму. Для реализации динамического обновления списков на формах необходимо периодически выполнять обновление формы, что каждый раз влечет за собой выполнение запросов к БД. Для реализации теневого контроля за изменениями данных в регистрах сведений, задачах и т.п. необходимо запустить обработчик ожидания, который будет периодически запускать процедуру, которая в свою очередь будет каждый раз выполнять запрос к БД. Недостаток синхронного обмена состоит в том, что если в решении необходимо обеспечить высокую актуальность данных, то период обновления форм или период обработчика ожидания необходимо задавать достаточно маленький. При увеличении числа активных клиентов число запросов растет в арефметической прогрессии и может вызвать ощутимую нагрузку на кластер (сервер) как 1С, так и SQL. Причем при небольшой интенсивности реального обновления данных (количества записей/перезаписей документов, элементов справочников, движения регистров и т.п.) большая часть запросов будет возвращать один и тот-же результат. Т.е. высокая загрузка серверов будет абсолютно не оправданной.
Ситуацию может изменить в корне принцип асинхронного взаимодействия клиента и сервера, когда изменение определенных данных вызывает процедуру обработчика события на занитересованных (подписавшихся на событие) клиентах. Сейчас платформа позволяет подписаться только на те события, которые возникают на текущем клиенте. Невозможно подписаться на событие, возникающее в другом сеансе. Все что можно получить- это список всех сеансов или соединений с текщей БД и при наличии прав- вызвать разрыв соединения. Нет механизма мгновенного оповещениия нужного сеанса о наступлении определенного события, которое вызывало-бы определенную процедуру обработки такого события.
Более детально идея реализации асинхронного взаимодействия заключается в следующем:
1) При старте системы (или открытии определенной формы списка) клиент инициирует запрос к серверу и получает текущий набор данных.
2) Клиент подписывается на определенное событие, указывая какие именно изменения данных его интересуют (с указанием фильтра) и процедуры- обработчика. При этом происходит запись в служебную таблицу БД пользователя, номера сеанса, описание события и фильтра. Таблица индексируется, что обеспечивает в будущем максимальную скорость выполнения запросов к ней.
3) Когда на каком-либо клиенте происходит указанное событие рабочий процесс на сервере выполняет запрос к служебной таблице и получает список всех подписавшихся на событие клиентов (сеансов). Далее рабочий процесс отсылает оповещения по полученному списку сеансов. Если соединение в момент оповещения вдруг оборвалось, то рабочий процесс делает то-же самое, что и в случае когда клиент передал серверу запрос и "отвалился", не получив результат запроса.
4) Когда клиент получает оповещение, на нем запускается указанная при подписке процедура обработки события (которая физически может выполняться на сервере, если это указано директивой). Именно эта процедура и выполняет либо обычный запрос, получая нужные новые данные, либо выполняет обновление формы (также как это сейчас происходит при нажатии на кнопку "Обновить" на форме, использовании метода Обновить() и т.п.). Что именно делать- разработчик пишет в процедуре.
5) При отписке от обработки события из служебной таблицы происходит удаление соответствующей записи. Удаление всех записей с соответствующим пользователем и номером соединения происходит также при удалении/закрытии соединения, повторной подписке на то-же событие и т.п.
6) Ни что не мешает клиенту, по мимо асинхронного механизма выполнить запрос по тем-же данным в любой момент времени (синхронный метод обмена), если так решит написать приложение разработчик.

Хотелось-бы знать мнение об эффективности описанного механизма взаимодействия.

Сообщение отредактировал Vofka - 20.03.12, 20:54

[Vofka]

Мне интересно, это всё вы средствами 1С хотите делать?

[logist]

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

Мне вот интересно пример - где есть такая необходимость...

[susanin]

Мне интересно, это всё вы средствами 1С хотите делать?

Естественно. Я знаю, что сейчас платформа поддерживает только синхронный метод обмена (запрос-ответ) между клиентами и сервером. Метод асинхронного обмена это пока только идея.

Мне вот интересно пример - где есть такая необходимость...

Есть необходимость когда к системе подключаются несколько сотен пользователей и необходимо обеспечить мгновенное оповещение (появление предупреждения и открытие формы списка задач) при появлении новой задачи пользователя. На сейчас это можно реализовать через обработчик ожидания с маленьким интервалом (к примеру 10 сек), но при увеличении числа активных пользователей растет общее число холостых циклов обработчика, которые не рационально грузят сервер кластера. Спасет только методика асинхронного обмена.
Также когда пользователи включают автоматическое обновление списков (таблиц) на формах, большая часть циклов обновления может отрабатывать в холостую. В предложенной методике обновление будет происходить только тогда, когда это реально необходимо (изменились данные списка).

[Vofka]

Что-то не стыкуется вот это

Все что можно получить- это список всех сеансов или соединений с текщей БД и при наличии прав- вызвать разрыв соединения. Нет механизма мгновенного оповещениия нужного сеанса о наступлении определенного события, которое вызывало-бы определенную процедуру обработки такого события.

и вот это

Далее рабочий процесс отсылает оповещения по полученному списку сеансов.

Я, собственно, не могу понять как и в какой момент подписавшиеся клиенты узнают о том, что произошло какое-то событие?

Сообщение отредактировал Vofka - 21.03.12, 13:10

[susanin]

Что-то не стыкуется вот это

и вот это


Я, собственно, не могу понять как и в какой момент подписавшиеся клиенты узнают о том, что произошло какое-то событие?

Я же писал в 1-м посте, следующее предложение: "Нет механизма мгновенного оповещениия нужного сеанса о наступлении определенного события, которое вызывало-бы определенную процедуру обработки такого события."
Это НЕ РЕАЛИЗОВАНО сейчас в платформе. Я описываю идею, которую отослал разработчикам, для реализации в платформе. Хочу знать мнение народа по этому поводу.

[Vofka]

Я же писал в 1-м посте, следующее предложение: "Нет механизма мгновенного оповещениия нужного сеанса о наступлении определенного события, которое вызывало-бы определенную процедуру обработки такого события."

И при этом в ответ на мой вопрос

Мне интересно, это всё вы средствами 1С хотите делать?

вы ответили

Естественно. Я знаю, что сейчас платформа поддерживает только синхронный метод обмена (запрос-ответ) между клиентами и сервером. Метод асинхронного обмена это пока только идея.

[susanin]

И при этом в ответ на мой вопрос

вы ответили

Это ИДЕЯ, которую я описал разработчикам 1С. Пока жду ответа, решил еще и на форуме поинтересоваться: будет-ли реализация этой идеи полезна другим разработчикам?
Аналогичная технология обмена между браузерами и WEB-сервером уже реализована в протоколе WebSocket. Описание протокола: [необходимо зарегистрироваться для просмотра ссылки] и [необходимо зарегистрироваться для просмотра ссылки]

[XBrut]

выглядит симпатично