Комментарии 41
Все системы с центральным узлом по определению ненадёжны.
Как-то самолетчики и автопроизводители об этом не в курсе. Сделать два хаба в избыточной схеме и получить заветные девятки надежности ИМХО проще, чем делать свой протокол.
Знают.
Два хаба — это тоже новый протокол, причём сложный — кроме прочего, нужно избегать дублирования сообщений, что требует схемы гарантированной идентификации пакетов, плюс ответа на вопрос: что делать, если пакет 2 с хаба 1 пришёл раньше пакета 1 с хаба 2.
Это всё решаемые проблемы, но, тупо, зачем? Предложенный метод проще.
Я проектировал сложные протоколы и управлял сетью с избыточностью через топологию. Имею опыт. Хочется простого.
ТУ154 был разработан в 1968 году. Вы действительно думаете, что современный Боинг и Аирбас все еще исповедуют его принципы построения надежных систем управления?
Взгляните хотя-бы на Fly-by-Wire — там стоит по три-четыре вычислителя с кворумом, каждый со своими датчиками и исполнительными устройствами. И везде за главную функцию отвечает центральный узел — вычислитель
Два хаба — это тоже новый протокол, причём сложный — кроме прочего, нужно избегать дублирования сообщений, что требует схемы гарантированной идентификации пакетов, плюс ответа на вопрос: что делать, если пакет 2 с хаба 1 пришёл раньше пакета 1 с хаба 2.
Для домашней системы, где обход отказа может составлять десятки секунд, можно спокойно применить состему с холодным резервированием — т.е. дублирующий хаб при работающем основном просто все время выключен. Если основной хаб накрывается, реле — ватчдог тупо переключает питание на дублирующий. Дублирующий грузится и начинает выполнять ту же работу.
Тупо и решает всю проблему с дублированием.
— Можно сделать дома холодный резерв. Но ЗАЧЕМ? И — кто будет следить за тем, что он готов и работает? И кто будет управлять реле? По какому признаку?
И, главное, цель-то в чём такого усложнения?
— Описанная Вами схема отличается от ТУ только названием компонент. Единственного центрального узла всё равно нет.
Как это нет? Там десятки, если не сотни датчиков, на основании данных от которых центральный вычислитель по сложному алгоритму определяет, что нужно делать исполнительным устройствам. Если этот вычислитель накрывается — весь канал (1 из четырех) считается неисправным. Если бы это была децентрализованная система, то датчики должны были бы непосредственно общаться с исполнительными устройствами, а такого в самолетах нет.
Можно сделать дома холодный резерв. Но ЗАЧЕМ? И — кто будет следить за тем, что он готов и работает? И кто будет управлять реле? По какому признаку?
Потому, что это просто! За резервным контролером следить не надо — он выключен до поры до времени и с ним вряд-ли что-то случится. За работой основного контроллера следит примитивная цепь, называемая в простонародье Ватчдог. В простейшем случае, это реле, которое удерживается в одном из состояний, если на вход периодически поступают импульсы. Импульсы пропали — реле переключилось и подало питание на резервный контроллер. Если эти импульсы будут поступать от основного контроллера — получите простейший ватчдог.
Цель такого усложнения такая же, как и вашего — получить более надежную систему. И в моем предложении не надо придумывать никакие протоколы.
Но, в принципе, меня больше всего волнуют именно датчики, а с ними всё и так хорошо. Выключатели я пока на этот протокол вешать не планирую. Правда, не из соображений надёжности, а просто потому, что они уже сделаны другим способом и реально бродкастить их на всю сеть нет потребности.
А вот датчики температуры — есть потребность отдавать в несколько мест.
Я почему-то думал что речь идёт о радиолинии, с общей средой. Для небольшого УД это логичней чем использовать Ethernet в каждом датчике и тащить к ним провода. Так-то да, если использовать обычные свичи то все будет работать. Но стоимость… Кстати в дешёвых свичах коллизии есть, просто клиентские Ethernet умеют детектировать коллизии и есть механизм повторной передачи так чтобы избегать повторной коллизии(ведь этим двум девайсам всё ещё надо передать свои данные после обнаружения коллизии), поэтому при маленьком трафике кажется что их нет. А свич с функцией store/forward уже больше похож на роутер, с соответствующим ценником.
Арбитраж CAN мало чем отличается от арбитража ethernet, а с подтверждением доставки проблема логическая, а не техническая. Сделать его банально, но мы, строго говоря, не знаем количество получателей и не уверены в том, что они работают постоянно.
Хранить на каждом передатчике карту получателей, собирать подтверждения, увеличить в разы трафик в сети, поднять требования к передатчику. Зачем? Датчик температуры всё равно отправит свою температуру через минуту снова.
И ещё. При дроп рейте пакетов порядка нескольких процентов TCP встаёт колом и не работает. Для датчика температуры потеря каждого второго отсчёта (дроп рейт 50%) несущественна.
Понятие надёжности ценно осознавать в прикладном аспекте, а не в абстрактном. В реальной свитчованной сети при отсутствии перегрузки по трафику вообще неясно, как UDP пакет может пропасть. Перегрузки по трафику для этой группы узлов быть не может (ок, всё может быть, но видимой причины нет).
При перегрузке и потере пакетов любой TCP протокол ляжет, а UDP будет прорываться, хоть и с кровью.
Внезапно, UDP… надёжнее для этого применения.
Внезапно, UDP… надёжнее для этого применения.
Я чего-то не пойму ваше понятие надежности. Центральный узел априори не надежный, а потеря пакетов — фигня, жить можно?
Система связи в системах автоматизации должна быть надежна. Вашему датчику температуры, возможно и пофиг, а событийному выключателю далеко нет. Не дошло от него сообщение — свет не включился. Надежно?
При перегрузке и потере пакетов любой TCP протокол ляжет
И это правильное поведение. Вы должны получить понятное состояние системы, а не метание между "работает/не работает".
В реальной свитчованной сети при отсутствии перегрузки по трафику вообще неясно, как UDP пакет может пропасть. Перегрузки по трафику для этой группы узлов быть не может (ок, всё может быть, но видимой причины нет).
В реальной свитчованой сети нет приоритетов и ваш UDP трафик будет крутиться вместе с теми же более надежными TCP/IP пакетами. У вас домашняя сеть для УД изолирована от всего остального? Компьютеров, телевизоров, телефонов? Если нет — проведите тест — попробуйте перекинуть два больших файла по сети через один свитч и проверить надежность вашей MQTT/UDP. Странно, но TCP/IP не ложится при этом, правда?
Предложенный Вами тест не имеет смысла. Если производительность свитча не упёрлась в полку, то две пары портов будут работать на полной скорости параллельно вообще не мешая друг другу.
Ну и да, я пробовал. :) Я пока умозрительно не вижу ситуации, в которой бы UDP начал терять 100% пакетов, а TCP работал бы. Вижу ситуацию, в которой TCP лежит, а UDP доносит половину.
Ну и практические ситуации, когда DNS работает, а HTTP не бегает мне тоже вполне встречались. Именно что когда дроп рейт становится ощутим. Даже при 10% потери пакетов TCP не жилец в реальности.
Вы как-то религиозно упираетесь в «защищённость» TCP — у неё есть своя применимость и свой порог осмысленности. Для передачи периодической информации, когда следующий отсчёт обесценивает предыдущий, TCP тупо вреден.
Кстати, это хорошо понимают люди, которые разрабатывают голосовые и видео протоколы реального времени. Если кадр N+1 пришёл, то кадр N тупо не нужен, а следовательно не нужен и TCP.
И ещё, в CAN не арбитраж, а отсутствие коллизий — передатчик автоматически определяет, что он может помешать другому передатчику и перестаёт мешать. Исходное сообщение от первого передатчика — не портится.
Карту получателей на каждом передатчике хранить не нужно, подтверждения тоже не нужно. Нужно только озаботиться, чтобы адреса у разных передатчиков не совпадали и всё.
Идея отличная.
Можете еще глянуть на эту статью https://habr.com/post/240053/ — там я описывал сходную идею на UDP multicast (не broadcast)
1) У Вас в любом случае есть центральный узел — роутер или иное устойство, которое проводную и/или беспроводную сеть поддерживает, разве нет? Упадёт он и никуда никакие UDP пакеты не дойдут.
- Насколько вероятен отказ центрального хаба? Те же роутеры работают месяцами-годами. Допустим, что будет программный отказ (повиснет). Тогда достаточно вочдога, который его перезагрузит. А какая вероятность аппаратного отказа?
То есть, конечно, можно и сеть резервировать, но никто этого дома делать не будет.
Сразу скажу, что проводную сеть резервировать очень дорого. С STP/RSTP в одноранговой домашней сети особо много не сделаешь, а полное дублирование по типу PRP/HSR требует соответствующего железа.
С этой точки зрения безпроводка — отличная штука. И мой подход выше тоже. На ту же переключаемую розетку вешаем еще и беспроводной роутер с теми же настройками и получаем резервную сеть.
У меня, правда, почти все датчики и устройства не на Wi-Fi, а на Z-wave, поэтому протоколами вообще не заморачиваюсь и резервирование центрального контроллера Z-wave вообще плевое дело.
Как сoбственно мы и сделали в своём проекте Enviriot
Есть устройства ethernet/rs485/rf, сервер работающий под виндой либо линуксом.
На случай полного отказа центральной системы был прикручен маленький PLC в сами устройства. На сервере есть «большой» PLC с FBD либо JavaScript.
Гарантия доставки пакетов это часть протокола для QOS 1/2.
Даже по RF на 868/443MHz всё работает достойно.
Дублирование сервера то-же часть протокола. Устройства автоматически находят активный гейт/брокер.
А модификация протокола который изначально построен по принципу устройство — определенный гейт — это сова на глобусе.
«The CONNECT message is split into three messages. The two additional ones are optional and used to transfer the Will topic and the Will message to the server.»
Нафиг коннект! Есть имя топика в пакете? Есть пакет? Есть получатель, которому нужен этот топик? Отлично.
Никогда в жизни ещё не видел, чтобы IBM хоть что-то сделал просто. :)
И кстати, в самом MQTT фазу Connect опустить не возможно. И адрес гейта надо просто знать, если гейт упал, упс. Представьте как весело в сети с DHCP.
А в MQTT-SN можно, QOS — 1 в помощь.
Выглядит следующим образом:
1. Нода с пустой прошивкой шлет: Search Gateway.
2. Гейт отвечает: GWInfo
Если адрес гейта нам известен первые 2 пункта можно опустить.
3. Нода шлет Publish QOS-1, ответ на сообшение не требуется.
Обмен с CONNECT'ом
1. N. SearchGW
2 G. GwInfo
3. N. Connect, w/o will
4 G. Connack
4 N. Publish with QOS 1
5 G. PubAck
Если ноде что то надо от сервера, т.е. если сервер должен посылать ноде какие либо данные.
6. N. Subscribe *
7. G. SubAck
Всё, мы взяли ноду с пустой прошивкой, она САМА нашла к кому подключаться. И у нас уже работает двухсторонний обмен.
Собственно мы пилили сперва свой протокол, потом наткнулись на MQTT-S тогда ещё.
Оказалось что мы практически скоммуниздили один в один, и для совместимости обошлось практически только правкой дефайнов.
Проще, чем MQTT? MQTT/UDP