Здравствуйте, 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Гц. И сотней-другой операторов, которые подписываются на актуальные метеоусловия в заданных регионах (история их не интересует) и хотят видеть их в браузере. Ну и центральным архивом, куда должны копироваться все проходящие данные.
