[:-) 0]

Добрый день!

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

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

[Lmx2315 2]

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

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

[psyhologic 0]

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

Добрый день!

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

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

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

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

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

[:-) 0]

1 hour ago, psyhologic said:

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

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

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

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

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

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

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

[psyhologic 0]

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байт/с телеметрии ... не заметил, извиняюсь. Что это у вас за телеметрия то такая ?

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

[AlexandrY 2]

1 hour ago, psyhologic said:

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

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

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

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

[psyhologic 0]

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

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

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

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

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

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

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

[k155la3 26]

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 ?

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

[psyhologic 0]

 

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

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

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

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

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

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

[AlexandrY 2]

22 minutes ago, psyhologic said:

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

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

[psyhologic 0]

Только что, 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.

[HardEgor 63]

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

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

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

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

[:-) 0]

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. На ПК предполагается специальная программа для пользователя.

[AlexandrY 2]

1 hour ago, :-) said:

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

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

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

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

 

[k155la3 26]

15 hours ago, psyhologic said:

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

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

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

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

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

IMHO