Обновление страниц у всех пользователей - веб
А там сказано о том что если я добавлю в приложение какую-то фигню его нужно обязательно назвать сервером
Нет. Сервер -это тот, кто предоставляет какие то ресурсы в пользование. Но веб-сервер действительно сидит и ждёт. А клиент умеет только спрашивать и на один вопрос он ждёт точно один ответ. И не слушает если не спрешиваl . В принципе можно что то придумать, но в идеале сервер ничего не может сообщить клиентам - он их не знает, а они его не слушают.
Можно что то придумать. Или клиентский запрос без таймаута(с длинным таймаутом и сразу последующим запросоm). Спросил, сервер вопрос услышал, сессию открыл и пока не отвечает. Или клиент долбит сервер короткими вопросами "изменений нет?". И на положительный ответ уже забирает эти изменения.
Хочешь быть упертым - будь!!!
Да по большому счету, мне по барабану. Нужно задачу хорошо решить. Лучше бы рассказал как лучше событие сгенерировать.
Но в итоге мы просто смотрим по другому.
Вот например, полечу я в космос с Безосом, будет ли меня интересовать что такое "Ever Green" - неа, интересно на шарик посмотреть.
А вот жду я поставки из Китая, будет ли меня интересовать космический корабль, неа, а вот другой кораблик будет уже интереснее. И в любом случае речь идет о планете Земля. 
Но поскольку это уже не "веб-приложение"
А что?
Лучше бы рассказал как лучше событие сгенерировать.
-----
Ну написано же - в рамках определения - "веб-приложение" - никак. Просто нет механизма для обращения сервера к клиенту.
Ну а если нужного механизма нет - то остается, в рамках "веб-приложения", - поолинг.
Есть ли какие библиотеки с более-менее приемлемой реализацией - не знаю, не требовалось.
Грубо говоря - тебе нужно выполнять со страницы асинхронный запрос - получишь "слушающего" клиента
и не отвечать на него пока не произойдет "событие". По тайм-ауту - обновлять. Но ресурсов сервера это будет жрать будь здоров.
Ну написано же - в рамках определения - "веб-приложение" - никак
Как то мы их по разному понимаем
https://metanit.com/sharp/aspnet5/2.7.php
"SignalR использует двунаправленную связь для обмена сообщениями
между клиентом и сервером, благодаря чему сервер может отправлять в режиме реального времени всем клиентам некоторые данные."
https://metanit.com/sharp/aspnet5/30.1.php
Но речь то шла не об этом, а только о генерации события, что вот появилась новая запись времени на приём, кого интересует дата Х и адрес Y, обновитесь.
не об этом, а только о
-----
В рамках "веб-приложения" того что тебе нужно - нету. Просто нету.
Есть - запрос с клиента и ответ от сервера. Обратного - нету.
Если где-то пишется об двунаправленном обмене, то самый простой
вариант похерить всю эту галиматью - попросить сервер закачать "событие" на выключенного клиента.
Повторюсь - чтобы сервер мог что-то отдать клиенту клиент должен его слушать.
В "веб-приложении" клиент "слушает" только ответ на свой запрос. Больше - ничего.
И нет никаких других вариантов.
Стандртно - очередью.
Верно. Если ресурс по определению единственный (а одна и та же дата - единственная), до доступ к нему - по очереди.
Тогда ты не можешь ничего сообщить клиенту - в вебе сервер только отвечает на запросы.
Если с очередью, то клиент просто ждёт результат выполнения - если прямо перед ним дата занята оказалась, то приходит отказ и предложение выбрать другую дату.
Для 1 - вероятно лучше всего сделать сигнал обновления с базы, а затем как то переслать всем у кого открыта страница с календарем signalR?
Если послал запрос, то есть таймаут на ответ. За этот таймаут должен оформиться заказ даты у конкурирующего пользователя и прислаться ответ с предложением выбрать другую дату. Если нагрузка настолько велика, что очередь на сервере не успевает отработать все одновременные заказы за время таймаута, то надо предусмотреть состояние ожидания ответа (состояние обработки запроса) - в этом состоянии клиент периодически шлёт запросы на сервер на результат ожидания.
Правильно сказали, что если обработка запроса очень долгая (секунды, например), то лучше в очереди делать самую быструю начальную обработку и отсылать результат клиентам, что мол дата зарезервирована, а всю остальную работу отослать в параллельный поток.
ссылки говорят обратное
-----
Если клиент "слушает" - он уже сервер...
Внутри "слушания" вполне может быть обычный цикл, периодически опрашивающий сервер на предмет результата обработки запроса. Тогда сервер должен знать, что был запрос и его опрашивают о нём. Готовые библиотеки скорее всего просто всё это инкапсулируют с удобным программным интерфейсом.
Как я понял, задача сводится к общению в классическом примере слабой связи между объектами - типа однонаправленного интерфейса. Классический веб к этому относится. Также обычно происходит общение через однонаправленные порты, типа serial port. Ну или всякие MVC-MVVM с их "запретом" на движение данных в двух направлениях одновременно.
Сюда же косвенно относится Dependency inversion principle с точки зрения потоков информации.
Тогда ты создаёшь систему состояний на сервере, и клиент, создавая запросы входит в эти состояния. Сервер отсылает клиенту инфу, в каком клиент сейчас состоянии для сервера. В принципе, таким образом обработку любого запроса можно раздуть до любого времени - необязательно укладываться в таймайт ответа от
сервера - хоть годами обрабатывать. И состояние может быть сколь угодно сложным. И обработка может даже прерываться и возобновляться. Классический пример - ММО игры. Игрок проходит игру, качается по уровням - для сервера это как обработка большого запроса на доведение игрока до конца игры. Эта обработка может длиться годами, а игрок может брать сколь угодно долгую паузу в любой момент обработки.
Ну и состояние может храниться и на клиенте и отсылаться серверу, чтобы сам сервер его не сохранял. Но опять же, если севрер не доверяет клиенту, то лучше, если сам сервер будет всё хранить или хотя бы дублировать дынные клиента. Короче, всё опять сводится к классической схеме клиент-серверных ММО с недоверчивым сервером, который сохраняет состояние клиента и верифицирует его.
Ещё раз, готовые библиотеки скорее всего всё это тоже делают, только инкапсулируют и предоставляют простой и удобный интерфейс наружу. Какие-нибудь навороченные - вообще поднимают сервер на клиенте, как тут уже говорили. Но последнее можно сделать разве что для платформ с широкими полномочиями, которые могут, скажем, запускаться как отдельные программы на машинах клиентов или как службы в операционной системе... или можно сделать клиентский сервер на джаваскрипт, живущий в контексте текущего запроса, но сохраняющий свои данные в куки и восстанавливающийся, если запрос прервался?
Впрочем, всё вышеописанное настолько усложнено, что, я думаю, запросы топикстартера скорее уложатся в таймаут ответа сервера, чем потребуется создание системы состояний... Кроме случая потери связи с сервером.
Там ничего не сказано об том, что веб-сервер как-то рулит браузером.
Учись читать
Также в последнее время набирает большую популярность технология WebSocket, которая не требует постоянных запросов от клиента к серверу, а создает двунаправленное соединение, при котором сервер может отправлять данные клиенту без запроса от последнего.
Читаем там же:
=====
Открытие канала WebSocket[править | править код]
Для установления соединения WebSocket клиент и сервер используют протокол, похожий на HTTP.
=====
И вспоминаем, что веб работает через ХТТП, а не через что-то похожее...
И что с того? WebSocket реализован во всех современных браузерах. Так что этот протокол уже является частью вэб-приложения.
JS и Ajax тоже появились позже HTTP с HTML'ом. Но никто сейчас даже не представляет себе вэб-приложения без них.
а не через что-то похожее...
И он не только похож, но и совместим с HTTP.
Интересно, что чтобы реализовать функциональность, которая в других областях разработки является базовой и давно уже никто не думает "как же это сделать?", в вебе всё ещё бьются над этой задачей и нужно изобретать дополнительные технологии, которые изначально в веб-стек не входили. Вот та же двухсторонняя коммуникация - судя по всему, это вообще против основ веба. Поэтому требуется отдельная сторонняя технология. И это за минимум четверть века активного существования веба. Вот за это я веб и не люблю - куча костылей и недоработок, отдельные инструменты на каждый чих, стандарты, которые никто не хочет толком соблюдать и постоянно изобретают свои проприетарные технологии, чтобы перетянуть одеяло на себя. Постоянно возникающие и умирающие фреймворки, решающие лишь узкий круг задачь, которые (фреймворки) нужно обязательно изучать, если не хочешь остаться на обочине. Даже если через 2-4 года этот фреймворк канет в лету.
Веб - это поле битвы корпораций, поэтому ничего устойчивого там быть не может. А невозможно нормально работать в постоянно изменяющейся, неустойчивой и так и не доведённой до ума, включая даже основной язык программирования, среде.
Веб - это поле битвы корпораций, поэтому ничего устойчивого там быть не может. А невозможно нормально работать в постоянно изменяющейся, неустойчивой и так и не доведённой до ума, включая даже основной язык программирования, среде.
чего там изменяется то? со времен XMLHttpRequest там кардинальных изменений то и нет, можно вообще в скрытый iframe спамить на сервер и парсить потом то что пришло ) работать будет века ))
просто веб это не частная лавочка, и довольно проблематично сделать так, чтобы работало сразу у всех и без проблем
просто веб это не частная лавочка, и довольно проблематично сделать так, чтобы работало сразу у всех и без проблем
Эти проблемы у этой лавочки с её основания и уже больше четверти века. Если эти проблемы до сих пор не решены, значит это никому не надо (борящимся друг с другом корпорациям - так уж точно). А все эти стандарты и словеса про "запускается везде" - для придания приглядного вида и чтобы надежды юношей не переставали питать.
В стандартном виде веб не нуждается в постоянном канале связи. Это значит, что если я запросил с сервера страницу и потом следующую, то наплевать, что в промежутке между вызовами пропадал интернет. Кроме того клиент, как правило, не имеет собственного адреса. За рутером могут сидеть сотни клиентов. Получается, что для стабильной работы клиент должен опрашивать сервер каждый раз заново.Как в первый раз.
Таким образом, если есть необходимость в интерактивном соединении(сервер должен сам закинуть что то на клиента без его участиq), то сервер должен держать открытое соединение, потому что прервав его, он больше не найдет клиента. Сколько открытых соединений может одновременно поддерживать сервер? Пару тысяч? В нормальных ословоях клиент спросил и отсоединился. И канал свободен.
Это проблема.
Если эти проблемы до сих пор не решены, значит это никому не надо
так а кто их решать должен, если веб ничей, это как лебедь, щука и рак. Как раз, если бы в веб засовывали все что попадя, любое пожелание, было бы еще хуже, нужно было бы дома два компуктера, один для работы и отдыха, другой для веба, где браузер это и есть операционка )))