Обновление страниц у всех пользователей - веб
Интересует как лучше всего решить задачу.
Хочу допустим заказать посещение кото то. У меня есть эвент календарь с занятыми часами/днями. Выбираю свободное и заказываю.
Тут возможны варианты:
1. Пока я думаю, кто то заказал еще, нужно значит обновить страницу с календарём.
2. Заказали одновременно, кто выиграет если время отсылки заказа полностью одинаковое? Хотя если и миллисекунды передавать...
Для 1 - вероятно лучше всего сделать сигнал обновления с базы, а затем как то переслать всем у кого открыта страница с календарем signalR?
Какой бесплатный календарь можете посоветовать C# ASP.NET Core 3.1. Пока только один нормальный нашел.
Так не бывает.
Почему? И ты и я заказали на 2 часа. Хочешь сказать что кто то обязательно придет первым? Тому и флаг в руки.
А как второго то отсеять если 1-й еще в работе?
Из клиента делаешь сервер и вперед
Не так не подходит, приложение должно остаться таким как есть.
SignalR похоже будет проще
https://dotnetplaybook.com/which-is-best-websockets-or-sig...
SSE
http://www.binaryintellect.net/articles/1b6d874a-3535-4af2...
https://www.twilio.com/blog/broadcasting-with-signalr-and-...
А как лучше эвент генерить?
А как второго то отсеять если 1-й еще в работе?
------
Стандртно - очередью.
Плюс - первого не обязательно доводить до конца - достаточно сделать только необходимый минимум. Но сделать - максимально быстро.
Не так не подходит
-----
Тогда ты не можешь ничего сообщить клиенту - в вебе сервер только отвечает на запросы.
А подробнее?
------
Пришел запрос. Обработка запроса - помещение его в очередь. Их несколько, Я пользовал мелкомягкую.
Дальше из очереди он вынимается и обрабатывается.
Клиента - либо (обычно) держишь, либо куда-то перекидываешь.
Из очереди - вынимаешь и выполняешь обработку.
Если есть желание - можно оценивать что есть в очереди на предмет наличия ресурсов для выполненния.
ссылки говорят обратное
-----
Если клиент "слушает" - он уже сервер...
не вижу места куда
-----
Бывает...
Тут смотри:
https://docs.microsoft.com/en-us/archive/msdn-magazine/200...
-----
Нормальное.
По крайней мере не создает путаницы в используемых терминах.
Ты хочешь рассматривать относительно чего то, а я рассматриваю как оно есть изначально
-----
То, что создает запрос является клиентом.
То, что обрабатывает запрос является сервером.
Никакой путаницы - ни относительной, ни изначальной.
У микросфота бессмысленно, что то смотреть
-----
Это - да.
Но именно по ссылке - с примерчиком.
ни разу не помогло для первого раза
-----
Ууууу... сказал бы проще - для меня сложно... жарко... пива хочу... и вообще - нафиг эту долбанную работу... 
Но именно по ссылке - с примерчиком.
Имеешь в виду это? Кликал?
Download the code for this article: HTTPFilters.exe (1,169 KB)
Никакой путаницы - ни относительной, ни изначальной.
https://ru.wikipedia.org/wiki/Веб-п�...
Веб-приложение — клиент-серверное приложение, в котором клиент взаимодействует с веб-сервером при помощи браузера. Логика веб-приложения распределена между сервером и клиентом, хранение данных осуществляется, преимущественно, на сервере, обмен информацией происходит по сети
все правильно. Есть клиент. Клиент как правило представляет собой набор ява-скриптов, хтмл и цсс. Вся эта хрень бегает в браузере . И при желании что то спрашивает у сервера
Сервер сидит и ждет. Спросят - ответит. Проблема в том, что по классической схеме сервер не может активно коммуницировать с клиентами. Он про них ничего не знает. Он тупо сидит и ждет, когда его кто то спросит.
Кликал?
-----
Зачем? Мне не надо - Я когда-то давно в этом копался, но откуда именно брал примерчики - не помню.
Учись читать:
=====
Веб-приложение ... взаимодействует с веб-сервером при помощи браузера.
=====
Там ничего не сказано об том, что веб-сервер как-то рулит браузером. 
Так по ссылке не нашел я никаких примерчиков...
------
Ну это к мелкомягким, наверное... Бо, я не трогал...
А там сказано о том что если я добавлю в приложение какую-то фигню его нужно обязательно назвать сервером?
-----
Хочешь быть упертым - будь!!!
Клиент - формирует запрос.
Сервер - обрабатывает запрос.
Какой запрос, как формируется, как пересылается, как обрабатывается и что возвращается - не важно,
Когда ты обрезаешь ситуацию до "Веб-приложение" у тебя автоматом налагается ряд ограничений.
1. используется протокол ХТТП(С).
2. клиентом является браузер или другое приложение которое умеет обрабатывать ХТТП(С) и ХТМЛ.
3. сервером является веб-сервер
Следствие - веб-сервер не может рулить клиентом. Хочешь/можешь/делаешь - уже не "веб-приложение".
Следствие - если клиент "слушает" запрос от сервера - значит все поменялось местами - "веб-сервер" является клиентом браузера, а браузер становится сервером для запроса с "веб-сервера". Но поскольку это уже не "веб-приложение" то на применяемый протокол начихать...
Вроде тута обсуждают и ссылаются на релевантные доки:
https://stackoverflow.com/questions/55507059/web-api-http-...