Коллеги, есть задача передачи данных с локальных компьютеров на удаленный компьютер(сервер) по запросу удаленного.

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

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

Т.е. клиент и сервер здесь меняются местами. Делается это с целью не публиковать локальный комп в интернет.

Локальные компы будут исчислятся десятками.
У кого был подобный опыт. Насколько правильно использовать веб-сервисы в таком режиме?

Подскажите центровой специализированный форум для обсуждения этого вопроса.

Посмотри в сторону SinalR
http://www.cyberforum.ru/asp-net-mvc/thread1093517.html

забыл уточнить - реализация предполагается на 1с

(0) Открой для себя протокол tcp/ip

(0)
Чето мне кажется, что задачу можно поставить по-другому.
Что опрашивает сервак?
Может клиентам просто передавать изменение состояния? По факту данного изменения.

(4) опрашивает клиент
как клиентам передавать с учетом ограничений описанных в (0) ?

(2) А разве 1С не поддерживает Ком объекты и сторонние вэб сервисы?

(6) поддерживает, а почему спрашиваешь?

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

а зачем для этого веб-сервис?

(9) через интернет

(7) К тому что SignalR можно реализовать в 1С.
ЕДинственно что нужно добавить сервис
http://metanit.com/sharp/mvc5/16.1.php

(11) посмотрю, спасибо

Клиент ниче опрашивать не должен.

Клиент должен подключиться к серверу и ждать, пока сервер чето пришлет одному из своих клиентов из списка Binding

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

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

(14) что это за технология, когда клиент подключается через интернет к серверу и ждет? как долго ждет?

(16) Митичкина и Асмодея спроси, насколько жизнеспособен их сервер...

(18) ты говоришь о обновлении по F5 или про регулярные автоматические вызовы?

(16) <насколько жизнеспособна такая технология>

Обычная технология, imho смысла нет придумывать чтото более извращённое

(19) эквипенисуально.
У меня форум настроен на автоматическое обновление, даже если меня нет за компом. И я, уверен, не один такой

(20) если обычная то есть ли у нее название, описания?
по каким словам погуглить?

(17) Шта?
Обычная такая технология, по которой почти все в этом мире работает, кроме p2p сетей.
Асечка, Hamachi, etc.

А если просто постоянно сливать данные на центральный сервер из переферийных?

(24) есть такая тема. но интересно рассмотреть и (0)

(22) я даже незнаю как называется, я похожие штуки когда делал както не задумывался...:)

(23) я думаю в "кроме" можно добавить еще немало
тот же REST

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

(28) частый регулярные запрос - это проверка наличия флага

(28) всё от размера сервера зависит, плюс при желании это всё кластеризуется

(25) Работать будет. Но имхо, изврат. Проще все же добиться опубликования локальных баз тем или иным способом. Да хоть впн поднять.

(31) не изврат, смотря какие цели. например собирать данные со 100500 распределённых устройств

(29)(30) Берите, тестируйте. Вот сайт (в разработке), который хостится на достаточно слабом виртуальном сервере, при обновлении страницы по описанной мной в (15) технологии дергает 1С, та возвращает ему текущую дату, эта дата выводится на странице: http://v-can.ru/test/
На сервере 1С сейчас включен режим debug, то есть, в реальности 1С будет отвечать быстрее. Без нагрузки страница открывается примерно за 3-4 секунды. Ломитесь, F5кайте, мне самому интересно, как скоро он умрет. Сайт пока еще не работает, так что можно ddosить.

(30) В качестве сервера 1С юзается десктоп на 3-хядерном атлоне, велосирапторах с 10000 об/мин и 16 гигами на борту. База файловая.

(34) тут всё в 1С упирается, в (0) же нет подробностей про остальную инфраструктуру

сам по себе метод передачи данных на вебсервер более чем масштабируем по производительности

(35) Ну вот я сейчас смотрю - или никто не тестит, или все отлично работает. Тормозов не заметно.

+(36) Вчера клиенту на сайт поставили такую связку сайта и 1С, у них там посетителей куча, каждый день по несколько человек новых регистрируется, не говоря уже о постоянных посетителях. За сутки никаких проблем не выявлено, все пашет.

блин я только чтотыкал пару раз.. раньше в опере было что-то типа автообновление страницы раз в N сек, ща не нашел

(37) правильно я понимаю, что http-сервис и web-сервис по ресурсоемкости идентичны?

(39) Нет, http легче

(40) Чуть чуть. Для 1с при подключении еще использует
v8: Web сервис, момент подключения
Для многих случаев можно для вэб сервисов просто упростить УстановкаПараметровСеанса
Для HTTP сервиса тоже вроде УстановкаПараметровСеанса срабатывает.

http://v8.1c.ru/o7/201312http/index.htm
Публикация HTTP-сервисов выполняется аналогично тому, как публикуются web-сервисы. Также аналогичным образом для них работает аутентификация, использование разделения данных и отладка.

http://forum.infostart.ru/forum86/topic120770/

(32) Если опрос идет часто (чаще чем раз в минуту), то давать серверу минимум 1675+ лишнишних запросов в секунду - нафига? Если эта информация нужна постоянно - проще ее сливать постоянно. Если она нужна периодически - зачем оперативность раз в минуту? В общем, непонятненько.

(15) Давным давно уже народ перешел на WebSockets или более всеядную SignalR.
push notifications уже везде применяется
https://ru.wikipedia.org/wiki/Технология_Push

http://itkeys.ru/about-push-notifications/

(43) Ни разу не юзал, но ознакомлюсь

(46) Вот простейшая реализация http://metanit.com/sharp/mvc5/16.5.php

(42) > Если она нужна периодически - зачем оперативность раз в минуту?
чтобы сервер мог получить нужную ему информацию когда ему понадобится
запрос может быть разный, например разный период выборки, т.е. нет цели выгружать всё
можно конечно выгружать всё заранее, но в (25) уже ответил

(46) https://dev.1c-bitrix.ru/api_help/push&pull/index.php

https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=41&LESSON_ID=2033

(16) "вопрос был, насколько жизнеспособна такая технология, когда масса клиентов будет долбить сервер "

Эээээ в общем вебсервер  для этого и предназначен ... разруливать массы.

(51) Ну как бы грузовик тоже предназначен для того, чтобы развозить грузы. Только вот какой-нибудь камаз-самосвал легко может увезти столько песочка, под которым удастся похоронить пару хюндаев-портеров.

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

http://metanit.com/sharp/mvc.php

(53) особенности поведения определяет реализация.

(13) чей то? инициатива клиента в обмене с сервером это абсолютно нормально. ибо клиенты как правило черти где сидят, и нет у них статики и постоянного онлайна в отличии от сервера.

У нас так программа собирающая отчеты с касс работала. Клиенты проверяли он-лайн и наличие новой инфы. Ели все ок, отправляли данные.

(56) а в каком режиме клиенты проверяли онлайн? с какой периодичностью?

(57) Это была не 1С говорю сразу. На клиенте ставили сервис виндовый. Интервал 3 минуты. Асинхронный (параллельный) обмен с клиентами. Протокол свой по TCP, сжатый, шифрованный. Соединение устанавливается от клиента (филиала) к серверу.

коллеги, спасибо за интересную дискуссию
по прежнему интересны ваши мнения по теме

(44) интересное преложение из статьи про push:
"Push-запросы могут быть смоделированы и с помощью регулярных pull-запросов, как это происходит, например, при извлечении сообщений электронной почты с сервера POP3, когда почтовый клиент делает запросы каждые несколько минут."

http://javascript.ru/node/75

(59)http://v8.1c.ru/o7/201502push/index.htm