Как по сети оповестить одного из сотен-тысяч клиентов?
Клиент-серверная архитектура (HTTP), у сервера могут быть сотни или тысячи клиентов, но они все мало работают с сервером (например, для них появляется что-то новое раз в час или даже раз в неделю). Но когда появится что-то новое для клиента, то хочется как-то быстро "пнуть", оповестить клиентское приложение с сервера. (Даже никакой информации передавать не надо, достаточно просто чтоб на клиент пришел сигнал, а там уже он полезет на сервер и разберется)
Клиент - собственное приложение, на python, крутится на linux (десктоп).
Как организовать это оповещение? Хочется решение и простое и безопасное и легкое для сервера.
Наверное, подошел бы RabbitMQ или другой message broker, но не хочется пускать в rabbitmq много не доверенных клиентов. (Безопасно ли это?)
Сейчас рабочая версия - сделать websocket сервер и через него оповещать. Но это тоже не очень нравится:
1. Все равно будут сотни коннектов (даже пустых), это, может быть нагрузкой на сервер
2. Как поведут себя коннекты если по нему сутки не будет ничего пролетать?
3. Есть ощущение, что это будет какой-то "велосипед", повторение уже созданной задачи.
Есть ли готовый сервер для таких задач (задача-то типовая, как мне кажется)?
Может быть есть даже сервис, чтобы на своем железе ничего не крутить, а мое серверное приложение само будет клиентом для сервиса, отсылать оповещение в сервис, откуда уже его будут получать клиенты?
Ярослав, https://docs.python.org/3/library/http.server.html
У клиента в отдельном треде запускаешь serve_forever(), живёшь себе спокойно, ожидая запросы с сервера.
Зачем тут лонгполлинг, вебсокеты? Особенно когда в задаче явно написано, что оповещение, в виде хттп запроса с сервера, будет кидаться раз в неделю.
javedimka, ну не в крон же пихать. Это отдельное приложение. Не надо трогать систему. Пусть внутри сидит демон и периодически опрашивает приложение. Но локально http сервер поднимать это бред. До него нельзя будет достучаться в большинстве случаев. Как и не разрулить будет трафик если несколько приложений в одной сети. Не рабочий вариант
javedimka, клиент это клиент. до него нет сетевого доступа, он может быть за файрволом, за NAT'ом, постоянно менять IP адреса, иногда выключаться на время, а потом подключаться. но когда он подключен - он должен быстро получать оповещения. Поэтому, крутить на клиенте HTTP сервер не получится :-(
Ярослав, и как описанные проблемы решает вебсокет и тем более лонгполлинг? Клиент ушёл в оффлайн и сменил интерфейс? Ну пусть при запуске оповестит сервер что такой-то клиент теперь здесь, а слушает вот здесь, а если были сообщений новые, ну так сервер в ответе на такой запрос их и вернёт.
Если хочется все посложнее сделать, то смотри cloud mqtt провайдеров, их полно
Иван Шумов, А я и не предлагаю по крону этого делать. Про «локальный» веб сервер мне претензии непонятны
вебсокет хорош тем, что сервер у нас на сервере, а клиент - клиент. может и за NAT'ом быть. В этом случае, запускать вебсервер на клиентской машине нет смысла - мы просто не достучимся ведь до нее. (я согласен, так было б гораздо проще, нужный URL дергать изредка).
