Как серверу вызвать событие на клиенте? #598556

Архитектура- клиент-сервер. Задача: нужно чтобы сервер вызвал определенную процедуру на определенном клиенте, подключенном к серверу. Можно-ли это реализовать и как? (Это что-то сродни принципу работы ICQ и тому подобного софта, когда не обработчик ожидания периодически опрашивает сервер, а сервер сам вызывает обработчик события на клиенте)

Никак, 1С ориентируется на протокол Http, соответственно никак. Пока не сделают вебсокеты или еще че нибудь не придумают, на уровне платформы.

обработчик ожидания на клиенте

что именно хочешь вызвать ?

Невозможно.

эмулировать через обработчик ожидания?

[когда не обработчик ожидания периодически опрашивает сервер, а сервер сам вызывает обработчик события на клиенте)]

Ну так конечно можно, но "Вызвать с сервера процедуру на клиенте" - невозможно.

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

в хранилище 7

Это неправильно. Забудь.

+1

В хоронилище... Тоже вариант Ага. То-то в винде callbackи вовсю используются. Да и в унихах тоже... Наверное, только Нуралиев и знают сокровенную истину...

через временное хранилище можно замутить, но это все извраты, врадли есть в этой задаче практический смылс, автор так таинтсвеннен словно достиг просветленной нетленной идеи, а я такой бухой, что мне па-барабану)

было тут: можно и в параметрах сеанса, но это как сказал

запилят вебсокеты можно будет. Сейчас нет.

хранилище зато для всех доступно

вдруг нужно будет всем клиентоса разослать всякую куйну ! хотя если бы было озвучено = всё было ясно

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

pumbaEO, прав в и , любое решение сейчас, это будет по любому через опрос клиентом сервера. Нужен аналог вебсокетов.

А в чем проблема клиенту с периодом в ннн секнд считывать процент выполнения?

наиболее логично чтобы он писал куда-то в базу результаты своих телодвижений, а клиентура спокойно читала сей манскрупти, как Будда, сидя на слоне, завывал "амммм-амммм"

да хрень это все - сервер должен пахать, а все попытки его дуплить от лукавого и нечего делать

а вот и в этом решение (см. выше) сам не догадался. Кстати, в винде той же я могу из длительной обработки обновить окно клиента, причём вне зависимости от желания клиента. А тут не могу. Криво это, знаете ли.

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

а эта шняга СообщениеПользователю только по окончанию отправить :?

Это таки да, но как написал pumbaEO 1С еще не доросло до вебсокетов, это пока еще новая технология. По протоколу хттп такое как бы невозможно, а 1С в режиме тонкого работает по нему. Сейчас продвигается это но оно нарушает стандарты хттп. Короче когда реализует 1С вебсокеты тогда будет гуд.

угу я ж говорю, через опу сделали

Не нужно путать божий дар с куем. Винда, использующая колбеки, выполняется на 1 компьютере. Если бы первое открытие папки "Мой компьютер" производил бы сервер в США, а второе - резервный в Европе, колбеков с клиента на сервер в ней точно не было бы. Всем, придумавающих через какую опу это таки сделать - продумайте, чтобы оно продолжило работать при внедрении отказоустойчивого кластера. Если будет - не радуйтесь, не факт, что это ВНЕЗАПНО не перестанет работать после очередного апдейта.

Сервер - он на то и сервер, чтобы делать то,  что его просят, а не тыркать всем тыщам клиентам, что им надо делать

сейчас всё стало настолько условным... если сервер пошлёт запрос на клиент, то уже сервер будет клиентом, а клиент - сервером %

за счет полного дуплекса достигается и более высокая скорость реакции и большая экономия как по трафику так и по нагрузке на сервер и на клиента: допустим у вас каждый из 100 клиентов через каждые 5 сек будет теребить сервер отсылая запрос "ну чо там, сделал или нет?" за 1 минуту 100*30/5 = 600 запросов к серверу. А если сервер сам отправит клиенту "сделал то-то" то получим всего 5 запросов с "сервера" к "клиенту", а каждый запрос то трафик и доп. нагрузка на сервер и на клиента. Не зря вебсокеты придумали, не зря.

а если на стороне сервера кластер, и запрос обрабатывается частями на разных узлах кластера (в 1С пока такого нет, но вдруг?), и несколько узлов станут пинать клиента что-то сделать, что получится?

сервер на то и сервер, чтобы обслуживать много запросов и сразу.

ну так пинать будет центральный агент, а он один

с чего бы ему пинать? у агента задача своя есть: нагрузку по серверам раскидать. А вы хотите со всех узлов дёргать агента, чтобы он дёргал клиентов… ууу!…

погорячился, не агент, а менеджер, конечно. думаешь, не справится?

хоть горшком назови. в любом случае, поскольку сервер сам не может инициировать соединение с клиентом, то как-то ему придётся поддерживать то соединение, которое начал клиент, постоянно спрашивая того: "эй, ты там ещё живой?"

инициирует соединение клиент, просто TCP-соединение остается открытым, клиент слушает открытый порт и получает данные от сервера, о том как это работает можете почитать тут: За этим будущее ;-)

опередил не мешает же это работать скайпам, аськам, и прочим

Да, WebSocket это именно то, что нужно. На сегодня браузеры Google Chrome (начиная с версии 4.0.249.0), Apple Safari (начиная с версии 5.0.7533.16), Mozilla Firefox (начиная с версии 4) и Opera (начиная с версии 10.70 9067) реализовали поддержку этого протокола. Если 1С реализует эту технологию, то отпадет необходимость на клиентах указывать время обновления для форм списков. Это снизит бестолковый трафик и нагрузку сервера бестолковыми запросами в разы! А в системах, где работает не одна сотня, а то и тысяча пользователей (а именно на это и замахнулась версия 8.2) это очень существенно! Кардинально менять ничего не надо. Надо только реализовать возможность подписки на событие записи ряда классов объектов другими клиентами. Так, чтобы к примеру при проведении документа, обработчик события на клиенте-инициаторе позволял "уведомить" определенных или всех подписавшихся на это событие клиентов. При получении уведомления, на "клиенте-слушателе" должна отрабатывать определенная процедура (отличная от обработчика этого события на клиенте-инициаторе), которая и выполнит либо обновление формы, либо другие необходимые действия. Реализовать это в платформе я думаю не очень сложно, т.к. сервер "знает" и контролирует каждое подключение к базе. Следовательно не сложно реализовать и уведомление заинтересованных клиентов о наступлении определенного события.

а теперь расскажите, чем _принципиально_ отличаются эти сокеты от коллбеков.

а метод "Оповестить" чо делает? он же посылает событие всем формам открытым

это всем, а если надо только одному.

Прочитай до конца, там написано, где этот метод доступен :)

Это как раз не проблема, по крайней мере пока у тебя не сотни открытых форм. Проблема в том, что это чисто клиентская процедура - для того, чтобы одна форма могла достучаться до другой _на_том_же_клиенте_ при надобности. Сервер тут вообще ни при чём.

заметка 9го года. Будущее так и не настало. Однако, не всё так радостно, как казалось на первый взгляд.

Метод "Оповестить" оповещает все открытые формы на этом-же клиенте. А необходимо оповестить не форму в этом-же приложении, а другое приложение, запущенное другим пользователем на другой совершенно машине. Я же писал в самом начале- так как работает ICQ: клиент на одной машине отправляет сообщение, другой клиент не "теребит" сервер каждые 5 секунд, как это делают почтовые клиенты, а просто "слушает" определенный порт. Когда на этот порт начинают поступать пакеты, клиент "просыпается" и начинает их обрабатывать, получая сообщение. Про WebSockets можно почитать здесь: На сколько я понял колбэки реализованы на протоколе http, который априори не является полнодуплексным (асинхронным). По этому колбеки это только эмуляция асинхронной работы сервера и клиента, а вэб-сокеты реализуют именно полноценный асинхронный (полнодуплексный) обмен.

( Будущее уже настало. Читаем Документ имеет статус "Предложенный стандарт". Такой статус имеют не мало протоколов, методик и т.п. используемых в Интернете. На сегодня протокол поддерживается всеми популярными браузерами. Через пару-тройку лет (не раньше. Раньше ни одному документу Комитет IETF не присваивает этот статус) документ получит статус "Черновой стандарт". К слову протокол HTTP ( на сегодня также имеет статус "Чернового стандарта" еще с 1999 года, что не мешает его использовать всему Инету!