Всем привет! Имеется проект/идея, частично связан с железом, серверной частью, и мобильным приложением.
Суть проекта:
Имеются gsm модули, которые время от времени присылают через TCP сокеты в байтах на сервер. Сервер их парсит, сохраняет в бд, и дальше передает на моб приложения (HTTP/HTTPS, иногда в режиме реального времени, думаю тут использовать ВебСокеты). Уже несколько дней пытаюсь разобраться на чем лучше написать и как соединить два протокола запросов (HTTP/TCP) в одном фреймворке. На данный момент написал парсер TCP сокетов на asyncio.
Прошу мне помочь, так как уже определенная каша в голове:
1. на каком фреймворке лучше всего написать сервер? Так как Flask/aiohttp/Django имеют поддержку только ВебСокетов, а мне нужно еще как-то получать TCP сокеты.
2. Могу ли я просто через WSGI поднять два демона - допустим Flask(WebSocket + HTTP) и на втором демоне будет TCP сервер?
С таким родом задач никогда не сталкивался, поэтому прошу помочь, возможно кто-то уже проходил эту тропинку. Заранее благодарю за ответ!
Стоит написать два сервиса: Один будет принимать tcp-соединения от железа и писать информацию в БД, а второй будет обрабатывать http-запросы от мобильных приложений. Только websocket'ы для общения с мобильными устройствами - это плохая идея. Во-первых, батарею будет жрать, а во-вторых, будут частые обрывы. Лучше использовать push-уведомления и краткосрочные соединения.
по пушу для мобилок - для разовых уведомлений вещь хорошая (чтобы юзер зашел в приложение), но как часть проекта - надо передавать данные, которые парсятся через TCP-соединение в режиме реального времени на мобилку. Приметил для себя socket.io, у них и для Python есть библиотека и для Swift. Два сервиса - хороший вариант, но тогда подскажите, пожалуйста, как мне с в режиме реального времени передавать данные с TCP сервера на HTTP, который потом будет на мобилку передавать? Потому что мне пока в голову пришло следующее:
1. Мне приходит TCP сокет, я с TCP сервиса делаю push-уведомление на мобилку.
2. Если мобилка заходит, с нее делаю запрос на HTTP сервис узнаю ее айпи, передаю данные на TCP сервис.
3. Делаю WebSocket (скажу сразу, с ними не особо знаком, может там не нужен айпи), и когда приходит TCP сокет - парсю данные, передаю через WebSocket на приложение.
Краткосрочное соединение - если сессия будет, допустим, длиться 10 минут, нормальное ли решение стучаться с телефона каждые н-секунд на сервер за обновлением? Или Вы имеете ввиду что-то другое?
Сергей правильно расписал. Для ещё большей гибкости я бы посоветовал использовать очереди.
Тогда первый сервис будет парсить tcp-соединения и класть сообщение в очередь (RabbitMQ, Kafka). Вторая часть, которая будет бэкендом для мобильных приложений, будет читать ещё и очередь. При получении сообщения из очереди, записывает в базу и шлёт PUSH сообщение на мобилки. Также мобилки могут иногда сами запросить данные (при первом запуске или при pull-to-refresh фиче, например), тогда ваше API вернёт данные из базы.
Если нужен прям реальный realtime, то тогда это вопрос другого порядка. Скорее всего нужно написать демона, который будет парсить tcp и транслировать UDP. А мобилки будут на это подписываться. Но тут есть нюансы с авторизацией и т.п. Зависит от вашего функционала. Но чаще всего настоящий realtime не нужен. Задержка в секунду более чем допустима для тех сервисов, которые нас окружают.
Спасибо! О таких инструментах как Кафка не знал, поэтому и была сложность в понимании как читать данные с одного процесса во втором (без бд, так как чтение с бд может затянуть процесс).
Про push/UDP тоже спасибо, свой взгляд на push (особенно silent push) пересмотрел, спасибо!
