у самого еще пазл не до конца в голове сложился, поэтому описание может быть технически не точным.
Пользовательская часть.
Система похожа на терминалы котировок. Пользователи через браузеры подключаются к серверу (облачный пул) и запрашивают одну или несколько категорий данных.
Поток данных идет мелкими пакетами и неравномерный во времени. Затраты на соединение слишком дорогие и думаю что удержание постоянного соединения — мой вариант.
Смотрю в сторону HTTP3/QUIC/WebTransport или WebSockets для реализации клиента на JS.
Облачная часть.
По сути, это группа софтовых маршрутизаторов, которые должны перекидывать потоки по заданным правилам.
Общая таблица маршрутизации (вероятно, redis-backed) содержит список подписчиков по заданным категориям и обновляется в реальном времени.
Маршрутизатор, получая на вход пакет, берет из таблицы список подписчиков и раскидывает им данные по выбранному протоколу.
Поставщик данных.
Здесь могут быть как UDP вещание, так и реализация чего-то на Android (типа того же QUIC/WebSockets/TCP, если найдутся библиотеки и если вообще реально удерживать канал на "спящем" Андроиде).
Вопрос:
С условием что нужна невысокая latency, но real-time не обязателен, встречали ли вы библиотеки, позволяющие реализовать указанную маршрутизацию?
Думал на базе nginx запилить что-то. Но может проще будет ZeroMQ или еще что подобное?
Здравствуйте, pva, Вы писали:
pva>Поток данных идет мелкими пакетами и неравномерный во времени. Затраты на соединение слишком дорогие и думаю что удержание постоянного соединения — мой вариант. pva>Смотрю в сторону HTTP3/QUIC/WebTransport или WebSockets для реализации клиента на JS.
Есть ещё вариант "long polling" и Server Side Events.
pva>С условием что нужна невысокая latency, но real-time не обязателен, встречали ли вы библиотеки, позволяющие реализовать указанную маршрутизацию?
Не обязателен ли? Все протоколы основанные на TCP будут вынуждены принимать порцию
данных уже возможно устаревшую (если были задержки, разрывы в связи и т.п.) и ситуация
может начать развиваться лавинообразно: задержка/разрыв, накопились данные от отправителя,
пока они передаются следующая задержка. Траффик встал.
UDP-based протоколы здесь смотрятся лучше. Но только без переповторов. Возможно WebRTC лучший выбор.
pva>Думал на базе nginx запилить что-то. Но может проще будет ZeroMQ или еще что подобное?
Лишний слой абстракции ничего не добавит никаких новых возможностей.
Здравствуйте, fk0, Вы писали:
pva>>С условием что нужна невысокая latency, но real-time не обязателен, встречали ли вы библиотеки, позволяющие реализовать указанную маршрутизацию? fk0>Не обязателен ли? Все протоколы основанные на TCP будут вынуждены принимать порцию данных уже возможно устаревшую...
Данные.
В системе все входящие данные делятся на "актуальные" (если метка времени пакета больше чем другие в этой категории) и "архивные".
Задача поставщиков данных приоритетно отправлять в облако актуальные данные и в свободные слоты времени "архивные" (приоритезация отправки).
Архивные — это не только данные с не последней меткой времени, но и те пакеты по которым не было подтверждения доставки (для UDP прийдется колхозить подтверждение самому).
Структура.
Модификация классического "N PUBLISHERS — N SUBSCRIBERS" в виде балансировщиков-маршрутизаторов нагрузки между ними: "PRIVATE PUBS — PUBLIC BALANCERS/ROUTERS — PRIVATE SUBS".
Статическим подписчиком у балансировщиков также будет "архиватор" данных, на который всегда сливается копия всех данных для постобработки.
Итого, на участке PUB-CLOUD нужно обеспечить доставку с подтверждением, восстановлением связи и повторами, потому как стандартный канал — 3G/4G с плохим покрытием.
Сейчас это реализовано в крупно-пакетном (где-то по 100-200 мелких пакетов разом) режиме через HTTP. А нужно перейти как можно ближе к потоковому.
В самом CLOUD обеспечить маршрутизацию данных на подписчиков, которые могут быть подключены к разным нодам в облаке.
Ну и на участке CLOUD-SUB требования уже попроще. Доставка может быть не гарантированной, поскольку нужны только актуальные данные, а выпадение не критично. Можно и UDP-like обойтись, в целом.
И желательно избежать зоопарка технологий.
Мне кажется, что WebRTC отпадает поскольку сосредоточен на потоковых аудио/видео данных.
"long polling" по описанию выглядит привлекательно, хотя и не так велики отличия от WebSockets. К тому же "long polling" и server-sent events ограничены со стороны браузеров в 6 соединений для HTTP < 2.0, да и скорее решают вопрос CLOUD-SUB, чем внутреннюю маршрутизацию.
В физическом плане можно представить себе подобную систему для нескольких тысяч датчиков температуры/влажности/итп, генерящих пакеты с частотой 2-5Гц. И сотней-другой операторов, которые подписываются на актуальные метеоусловия в заданных регионах (история их не интересует) и хотят видеть их в браузере. Ну и центральным архивом, куда должны копироваться все проходящие данные.
Похоже что многие варианты "готовых решений" сводятся к MQTT или аналогичным продуктам (ActiveMQ, BifroMQ, RabbitMQ etc). Соответственно, вопрос в брокере, который умел бы все нужное бесплатно
Вероятно HTTP/3 еще слишком молода, чтобы получить свой стек продуктов (p.s. Имеется в коммерческих брокерах).
