Jump to content

    
Sign in to follow this  
:-)

Какой протокол использовать поверх UDP или TCP

Recommended Posts

Добрый день!

Есть задача реализовать управление неким устройством через Ethernet-соединение (1G). Требуется управлять включением/выключением некоторых функций. Также требуется при необходимости получать телеметрию (скорость потока - 1..10 Мбайт/с, может и выше в перспективе). (На устройстве будет скорее всего FreeRTOS+lwip, но не исключен вариант и Linux).

И тут возник вопрос - какой протокол использовать поверх UDP или TCP соединения (ещё не выбрано)? Придумывать что-то своё? Или есть что-то типовое, что всеми используется?

Share this post


Link to post
Share on other sites

У вас данные судя по всему, одинаковые по объёму всё время . Придумайте структуру - управления и структуру квитанции и отправляйте эти структуры через ethernet.

Никаких протоколов не нужно будет . Структура буквальная - Сишная.

Share this post


Link to post
Share on other sites
1 час назад, :-) сказал:

Добрый день!

Есть задача реализовать управление неким устройством через Ethernet-соединение (1G). Требуется управлять включением/выключением некоторых функций. Также требуется при необходимости получать телеметрию (скорость потока - 1..10 Мбайт/с, может и выше в перспективе). (На устройстве будет скорее всего FreeRTOS+lwip, но не исключен вариант и Linux).

И тут возник вопрос - какой протокол использовать поверх UDP или TCP соединения (ещё не выбрано)? Придумывать что-то своё? Или есть что-то типовое, что всеми используется?

Протокол имхо выбирают под задачу. Есть разные сценарии - запрос / ответ, polling, publish / subscribe, etc.

Бинарный протокол (как выше упомянули, буквально просто копирование памяти) - скорость, но вам придется городить сборку пакета самостоятельно.

Готовые решения вроде HTTP / MQTT избавят вас от лишней работы и проблем.

Share this post


Link to post
Share on other sites
1 hour ago, psyhologic said:

Протокол имхо выбирают под задачу. Есть разные сценарии - запрос / ответ, polling, publish / subscribe, etc.

Бинарный протокол (как выше упомянули, буквально просто копирование памяти) - скорость, но вам придется городить сборку пакета самостоятельно.

Готовые решения вроде HTTP / MQTT избавят вас от лишней работы и проблем.

Сценарии использования видятся следующими:

1. Запрос параметра - возврат параметра;

2. Запрос телеметрии - непрерывный поток данных телеметрии до запроса отмены телеметрии.

Соединение точка-точка.

Share this post


Link to post
Share on other sites
33 минуты назад, :-) сказал:

Сценарии использования видятся следующими:

1. Запрос параметра - возврат параметра;

2. Запрос телеметрии - непрерывный поток данных телеметрии до запроса отмены телеметрии.

Соединение точка-точка.

HTTP REST

 

- Не забудьте подумать о многопоточности

- Ограничены в количестве запросов в секунду

- Можно пробрасывать через reverse proxy (устройство доступно в интернет из закрытой сети)

- Nginx proxy сможет писать логи доступа

 

А вообще датчики / телеметрию лучше через MQTT, но request / response модель придется реализовывать самому.

3 часа назад, :-) сказал:

Добрый день!

Есть задача реализовать управление неким устройством через Ethernet-соединение (1G). Требуется управлять включением/выключением некоторых функций. Также требуется при необходимости получать телеметрию (скорость потока - 1..10 Мбайт/с, может и выше в перспективе). (На устройстве будет скорее всего FreeRTOS+lwip, но не исключен вариант и Linux).

И тут возник вопрос - какой протокол использовать поверх UDP или TCP соединения (ещё не выбрано)? Придумывать что-то своё? Или есть что-то типовое, что всеми используется?

1..10 Mбайт/с телеметрии ... не заметил, извиняюсь. Что это у вас за телеметрия то такая ?

Все бортовые системы шатла, не иначе. 

Share this post


Link to post
Share on other sites
1 hour ago, psyhologic said:

А вообще датчики / телеметрию лучше через MQTT, но request / response модель придется реализовывать самому.

Вы с MQTT сами работали или цитируете первые ссылки с гугли? 
Про реальное использование MQTT можно читать здесь - https://habr.com/ru/post/388343/

Во внутренней сети от MQTT толку мало, а тем более от HTTP. 

Для того чтобы выбрать протокол надо ответить на несколько ключевых вопросов:
-какая мощность платформы (Cortex-M, Cortex-A... , объем RAM, ...)
-кто клиент трафика (аналитическая программа, пользовательский GUI, облака, сетевой накопитель...)
-заходит ли в сеть публичный трафик,
-предусматривается ли масштабирование сервисов у устройств,
-предусматривается ли сеть аналогичных устройств и если сеть, то кто будет администрировать сеть. 

Share this post


Link to post
Share on other sites
1 час назад, AlexandrY сказал:

Вы с MQTT сами работали или цитируете первые ссылки с гугли? 
Про реальное использование MQTT можно читать здесь - https://habr.com/ru/post/388343/

Во внутренней сети от MQTT толку мало, а тем более от HTTP. 

Для того чтобы выбрать протокол надо ответить на несколько ключевых вопросов:
-какая мощность платформы (Cortex-M, Cortex-A... , объем RAM, ...)
-кто клиент трафика (аналитическая программа, пользовательский GUI, облака, сетевой накопитель...)
-заходит ли в сеть публичный трафик,
-предусматривается ли масштабирование сервисов у устройств,
-предусматривается ли сеть аналогичных устройств и если сеть, то кто будет администрировать сеть. 

С MQTT работал и много, но под Linux. Как он поведёт себя под RTOS, вам виднее.

С такими объёмами «телеметрии» :crazy: request - response, нужен Xeon с TCP Offload’ом :sarcastic_hand:

Шутка ли 80 Mbit/s payload...

Share this post


Link to post
Share on other sites
4 hours ago, :-) said:

Сценарии использования видятся следующими:

1. Запрос параметра - возврат параметра;

2. Запрос телеметрии - непрерывный поток данных телеметрии до запроса отмены телеметрии.

Соединение точка-точка.

Если Вы не планируете качать в (или "из") Ваши удаленные узлы ("некие устройства") большие файлы, то использовать TCP нет смысла. Кроме того это даже снизит скорость (не приниципиально) и надежность соединения (потомукак TCP требует установления соединения и его сброса).

Используйте UDP ( в одном пакете умещается не менее 1к байт). Т.о. Вы можете опросить Вашу периферию отправив один (!) пакет UDP на требуемый IP, и получив 1 (!) пакет ответа. Единственное, что надо будет контролировать - таймаут, после отправки запроса и максимального ожидания ответа. Все !

Ни-ка-ких серверов, библиотек, протоколов (фактически это "свой" протокол). За целостность информации отвечает Ethernet и IP/UDP, поэтому даже генерировать - проверять CRC не надо. 

ps (2) "непрерывный поток" - не  по феншую. Всегда используйте запрос-ответ. Тем более 1G.

 

18 minutes ago, psyhologic said:

С MQTT работал и много, но под Linux. Как он поведёт себя под RTOS, вам виднее. . . . 

Шутка ли 80 Mbit/s payload...

И кто (где) будет брокером MQTT ?

Будет оправдано только если соединение через "дикий" интернет. Если у ТС интранет - то нет смысла.

Share this post


Link to post
Share on other sites

 

7 часов назад, :-) сказал:

(На устройстве будет скорее всего FreeRTOS+lwip, но не исключен вариант и Linux).

Тот же mosquitto на Linux-based устройстве. 

2 часа назад, AlexandrY сказал:

Про реальное использование MQTT можно читать здесь - https://habr.com/ru/post/388343/

Что я должен был тут почерпнуть ? имхо - пустая статья. Забейте в google: mqtt performance и увидите сравнение производительности разных брокеров под разными нагрузками.

Share this post


Link to post
Share on other sites
22 minutes ago, psyhologic said:

Что я должен был тут почерпнуть ? 

А то что предлагая MQTT надо предлагать и кодирование. Без соглашения о  кодировании MQTT пустой звук. 
Поэтому и закралось подозрение, что о MQTT вы знаете только понаслышке или с позиции юзера и я вам дал ссылку чтоб освежили память. 

Share this post


Link to post
Share on other sites
Только что, AlexandrY сказал:

А то что предлагая MQTT надо предлагать и кодирование. Без соглашения о  кодировании MQTT пустой звук. 
Поэтому и закралось подозрение, что о MQTT вы знаете только понаслышке и я вам дал ссылку чтоб освежили память. 

Согласен, MQTT лишь транспорт publisher / subscriber. Который хорошо вписывается в архитектуру микросервисов.

В одном из последних проектов, на compute pi 3 based устройстве, mosquitto напрягая процессор максимум процентов на 5 - справляется с 250 событий в секунду (JSON payload).

Правда мы не посылаем все эти данные в сеть, а агрегируем / кешируем, а только потом отправляем в облако по HTTPS пачкой.

43 минуты назад, k155la3 сказал:

Используйте UDP ( в одном пакете умещается не менее 1к байт). Т.о. Вы можете опросить Вашу периферию отправив один (!) пакет UDP на требуемый IP, и получив 1 (!) пакет ответа. Единственное, что надо будет контролировать - таймаут, после отправки запроса и максимального ожидания ответа. Все !

Безусловно UDP самый шустрый. Но скажите пожалуйста, вам не надоели ещё эти "велосипеды" с custom протоколами.

Я например, больше не покупаю устройства с самописными сетевыми протоколами. Почему ?

Потому - что интегрировать их тяжко, ошибок в них много, документация худая, а время программиста стоит дорого.

А потом как говориться - "вся рота идет не в ногу, один поручик шагает в ногу".

Давайте дождёмся от ТС ответа, что же это за 10 MB/s телеметрии такой.

Может из них можно сделать 10 KB/s и они прекрасно проскочат в MQTT и JSON.

Share this post


Link to post
Share on other sites
2 часа назад, psyhologic сказал:

Безусловно UDP самый шустрый. Но скажите пожалуйста, вам не надоели ещё эти "велосипеды" с custom протоколами.

Это вопрос скорости обработки. На 80Mbit обработать UDP серьезный процессор нужен, а этот поток еще куда-то нужно складировать/обрабатывать.

Я бы вообще спустился до уровня Ethernet-фреймов, но тут вопрос уже сети и её структуры.

Share this post


Link to post
Share on other sites
5 hours ago, AlexandrY said:

Для того чтобы выбрать протокол надо ответить на несколько ключевых вопросов:

-какая мощность платформы (Cortex-M, Cortex-A... , объем RAM, ...)
-кто клиент трафика (аналитическая программа, пользовательский GUI, облака, сетевой накопитель...)
-заходит ли в сеть публичный трафик,
-предусматривается ли масштабирование сервисов у устройств,
-предусматривается ли сеть аналогичных устройств и если сеть, то кто будет администрировать сеть. 

- платформа cortex-A

- клиент - некая программа для пользователя

- как таковой сети и не предполагается. В 98% случаях - вся сеть состоит из 1ого ПК и 1ого управляемого устройства. В 2% может быть несколько устройств (<5)

3 hours ago, k155la3 said:

ps (2) "непрерывный поток" - не  по феншую. Всегда используйте запрос-ответ. Тем более 1G.

А чем плох непрерывный поток? С первого взгляда он упрощает ПО на ПК, выполняющее функции управления и приём данных "телеметрии". ("Телеметрия" - это некие данные о состоянии устройства, передаваемые с темпом 1кГц. Запрашивать на ПК данные с темпом 1кГц - как-то страшно.)

MQTT с первого взгляда кажется избыточным. Вот видел альтернативу в виде CoAP ( https://en.wikipedia.org/wiki/Constrained_Application_Protocol ) - как будто попроще. Использовал ли кто-нибудь?

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

 

Текущее резюме из советов в теме:

1. Лучше UDP, чем TCP. Хотя и TCP тоже норм.

2. Писать либо свой протокол, либо MQTT.

 

Уточню пару нюансов:

1. Работа через большую сеть/интернет не предполагается и не требуется (хотя, если окажется опцией, то отлично). Ethernet выбран - потому что хорошая скорость и доступность почти на любом ПК.

2. Телеметрия - это режим работы при отладке прибора "на столе". В готовом устройстве будет только управление: вкл/выкл, выбор режима и т.д.

3. На ПК предполагается специальная программа для пользователя.

Share this post


Link to post
Share on other sites
1 hour ago, :-) said:

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

Да конечно она типовая, только вы не с того конца начали и не в ту ветку. 
В ветку надо было постить про ARM-ы.
А озаглавить как то Run-Time Debugging Tool
И все стало бы на свои места.

Рантаймные тулсы не затачивают для какого-то одного интерфейса типа Ethernet. Их затачивают под максимальную гибкость.
Они поддерживают тучу интерфейсов и стилей общения (мастер-слэйв, публикация-подписка, peer-to-peer, клиент-сервер и проч. )
Поскольку рантаймные тулсы довольно сложные проекты, то производители чипов используют их как способ привязки к себе.
Поэтому хорошие бесплатные рантаймные тулсы (и протоколы соответственно к ним) надо искать у ST, TI, NXP,   Infineon и т.д.
если выбрали не тот чип, то вам не повезло. Тогда идете в такие места как Micrium и просите за деньги ucProbe и API к нему. 

Делать велосипед на TCP и MQTT будет потерей времени. 

 

Share this post


Link to post
Share on other sites
15 hours ago, psyhologic said:

. . . Безусловно UDP самый шустрый. Но скажите пожалуйста, вам не надоели ещё эти "велосипеды" с custom протоколами. . . .

Нет, не надоели, - пока в этом есть смысл, именно ст т.з. "велосипеда" и цены - в буквальном, долларовом, смысле.

Возьмите, к примеру стандартнейший MODBUS и посмотрите, сколько стоят евойные шлюзы с Ethernet (цена от 500). Есть желание написать шлюз самому ?

Так Вы и получите реализацию, которую я предлагаю, почти "за бесплатно". А поскольку для ТС MODBUS в данном, debug, случае очень вреден (по причине впихуемости задачи ТС в MODBUS регистры), то и вопроса нет, что использовать. 

MQTT будет отличным решением если есть много публикаторов, много подписчиков, многггггго форматов (и не только JSON) все это "одновременнно".

IMHO

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this