Как по сети оповестить одного из сотен-тысяч клиентов?

Question

[Ярослав]

Клиент-серверная архитектура (HTTP), у сервера могут быть сотни или тысячи клиентов, но они все мало работают с сервером (например, для них появляется что-то новое раз в час или даже раз в неделю). Но когда появится что-то новое для клиента, то хочется как-то быстро "пнуть", оповестить клиентское приложение с сервера. (Даже никакой информации передавать не надо, достаточно просто чтоб на клиент пришел сигнал, а там уже он полезет на сервер и разберется)

Клиент - собственное приложение, на python, крутится на linux (десктоп).

Как организовать это оповещение? Хочется решение и простое и безопасное и легкое для сервера.
Наверное, подошел бы RabbitMQ или другой message broker, но не хочется пускать в rabbitmq много не доверенных клиентов. (Безопасно ли это?)

Сейчас рабочая версия - сделать websocket сервер и через него оповещать. Но это тоже не очень нравится:
1. Все равно будут сотни коннектов (даже пустых), это, может быть нагрузкой на сервер
2. Как поведут себя коннекты если по нему сутки не будет ничего пролетать?
3. Есть ощущение, что это будет какой-то "велосипед", повторение уже созданной задачи.

Есть ли готовый сервер для таких задач (задача-то типовая, как мне кажется)?

Может быть есть даже сервис, чтобы на своем железе ничего не крутить, а мое серверное приложение само будет клиентом для сервиса, отсылать оповещение в сервис, откуда уже его будут получать клиенты?

Comments

[Иван Шумов]

Кто является клиентом?

[Ярослав]

Иван Шумов, собственное приложение, так что, можно как угодно его реализовывать. Но не доверяем сильно клиентской стороне.

[Иван Шумов]

Ярослав, мобильное приложение?

[Ярослав]

Иван Шумов, нет, десктопное, под линукс. на питоне.

[Иван Шумов]

Ярослав, могу только посочувствовать тогда. Long-polling в помощь

[Ярослав]

Спасибо за слова сочувствия. :-) Ну и long-polling - уже хоть ключевое слово на нужную тему есть, так что, есть что гуглить.

[javedimka]

Ярослав, https://docs.python.org/3/library/http.server.html
У клиента в отдельном треде запускаешь serve_forever(), живёшь себе спокойно, ожидая запросы с сервера.
Зачем тут лонгполлинг, вебсокеты? Особенно когда в задаче явно написано, что оповещение, в виде хттп запроса с сервера, будет кидаться раз в неделю.

[Иван Шумов]

javedimka, я ничего про питон не говорил. Не додумывай)

Особенно когда в задаче явно написано, что оповещение с сервера будет кидаться раз в месяц.

да неужели:

например, для них появляется что-то новое раз в час или даже раз в неделю

не предсказуемый промежуток времени на самом деле

[javedimka]

Иван Шумов, Ну да я ошибся, соре. Но сути это особо не меняет, один запрос раз в час - это ни что

[Иван Шумов]

javedimka, ну не в крон же пихать. Это отдельное приложение. Не надо трогать систему. Пусть внутри сидит демон и периодически опрашивает приложение. Но локально http сервер поднимать это бред. До него нельзя будет достучаться в большинстве случаев. Как и не разрулить будет трафик если несколько приложений в одной сети. Не рабочий вариант

[Ярослав]

javedimka, клиент это клиент. до него нет сетевого доступа, он может быть за файрволом, за NAT'ом, постоянно менять IP адреса, иногда выключаться на время, а потом подключаться. но когда он подключен - он должен быстро получать оповещения. Поэтому, крутить на клиенте HTTP сервер не получится :-(

[javedimka]

Ярослав, и как описанные проблемы решает вебсокет и тем более лонгполлинг? Клиент ушёл в оффлайн и сменил интерфейс? Ну пусть при запуске оповестит сервер что такой-то клиент теперь здесь, а слушает вот здесь, а если были сообщений новые, ну так сервер в ответе на такой запрос их и вернёт.

Если хочется все посложнее сделать, то смотри cloud mqtt провайдеров, их полно

Иван Шумов, А я и не предлагаю по крону этого делать. Про «локальный» веб сервер мне претензии непонятны

[Ярослав]

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

[Иван Шумов]

Ярослав, любой http-based протокол будет работать так. вебсокет сам по себе тут избыточен

Answer 1

[Ильдар]

RabbitMQ не подойдет. Это для микросервисной архитектуры.
То что ты говоришь, называется web push уведомлениями.
Почитай алгоритм как они работают, и сделай также.
Вроде как есть https://gotify.net/ и клиент под него

Проблема с вебсокетами в том, что на каждого подключённого клиента, на сервере будет выделяться память. И если много клиентов одновременно будут держать открытые соединения, то может память сервера кончится, и надо будет масштабировать сервер.

Как вариант можно юзать UDP протокол. Там не тратится память. Но надо будет решить проблему с NAT. NAT на клиенте можно обойти через проброс портов на роутере. Есть даже автоматический проброс портов через UPnP. Но это не везде будет работать. Где не работает, там вебсокеты.

Как идея второй вариант:
Если обновления происходят раз в час, или раз в неделю, и задержка в 5-10 минут не критична, то можно следующее решение. Клиент по таймауту раз в несколько минут отправляет post запрос (чтобы не кэшировался), где будет возвращен timestamp с последней новостью. Можно даже создать 100к txt статических файлов для каждого клиента и раздавать их через nginx или CDN. А для того чтобы "пнуть клиента", достаточно в txt файл записать новый timestamp.

Comments

[Ярослав]

Это будет работать, если клиент - не браузер, а обычный консольный скрипт?

[Ильдар]

Вроде как есть https://gotify.net/.
Судя по его api https://gotify.net/api-docs там есть метод /stream. Он позволяет открывать websocket соединение для возвращения новых сообщений. (Websocket, return newly created messages).
Пишут что есть clientToken и appToken.
clientToken - для получения сообщений
appToken - для отправки
Вот даже какой то клиент для него написанный на питоне
https://github.com/atareao/gotify-indicator/blob/m...