Я полагаю, что делать QoS по принципу «точно получили все» муторно и неестественно для такой концепции. Для этого нужно мониторить список всех получателей, проверять все ACK-и, плюс трафик в сети будет в разы выше. У меня есть два варианта.
Первый — ждать одного подтверждения, и исходить из того, что в современной сети шанс, что один получил, а остальные нет практически нулевой.
Второй — ждать столько же подтверждений, сколько было к предыдущему пакету. Но тут сразу столько вопросов, что ну его нафиг.
Есть промежуточный вариант. Ждать одного подтверждения, но при QoS 2 и подтверждение имеет QoS, причём для каждого получателя в конфигурации указывается максимальный QoS. Например, настенный индикатор вообще на QoS не реагирует и подтверждений не отправляет. Уровень 0. БД хранения истории шлёт подтверждения только на пакеты с QoS 1. А основной процессор событий отвечает с QoS 2. Тогда и отправителям можно выставить уровни важности, и каждый из них будет дожидаться подтверждения от получателя своего уровня важности. Остальные получатели — по остаточному принципу.
Мало того, можно 9 пакетов слать без QoS, а 10-й — с высоким уровнем.
Вот это вот «всё через центр» я и хочу извести на корню. У меня два ПЛК110, OpenHAB, три модуля atmega, два Raspberry (и ещё два будут), один NodeMCU в работе, и ещё несколько экспериментальных. И хочется не думать о том, работает юниксовая машина, или нет — модуль управления климатом должен свои данные получать в любом случае. Сейчас он почти всё получает почти напрямую от датчиков температуры, но будут и другие датчики. Часть — запасные, часть — для более сложных алгоритмов. Хочу иметь конструктор, в котором от модуля требуется только умение говорить параметр на шину и читать параметр с шины.
Но большинство каналов у меня в квартире — именно датчики. Только прямых аналоговых входов pt1000 порядка двадцати.
Кстати, смысл QoS в обычном MQTT от меня ускользает. Если TCP работает, то доставка гарантирована и так. Если не работает, то какие биты в пакете не выставляй — всё прахом.
Энергопотребление вряд ли заметно на фоне остальной квартиры. Два блока питания на 100Вт суммарно, компьютер с OpenHAB — load average 0.08, то есть спит. Мелочь, которая стоит по квартире кормится с тех же блоков питания. Есть несколько десятков реле на 220 вольт, но тоже вряд ли уж они много едят. Думаю, в 200 Вт он точно укладывается суммарно.
По деньгам — сложно сказать. Вряд ли меньше ста т.р., вряд ли больше 200.
«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 хоть что-то сделал просто. :)
Для детектирования отказа датчика необходимо и достаточно знать о том, что пакеты от него не приходят. TCP не привносит в этом плане ничего. Напротив — напомню, при 50% дроп рейте TCP ляжет насмерть, а UDP будет проходить с вероятностью 50%.
Предложенный Вами тест не имеет смысла. Если производительность свитча не упёрлась в полку, то две пары портов будут работать на полной скорости параллельно вообще не мешая друг другу.
Ну и да, я пробовал. :) Я пока умозрительно не вижу ситуации, в которой бы UDP начал терять 100% пакетов, а TCP работал бы. Вижу ситуацию, в которой TCP лежит, а UDP доносит половину.
Ну и практические ситуации, когда DNS работает, а HTTP не бегает мне тоже вполне встречались. Именно что когда дроп рейт становится ощутим. Даже при 10% потери пакетов TCP не жилец в реальности.
Вы как-то религиозно упираетесь в «защищённость» TCP — у неё есть своя применимость и свой порог осмысленности. Для передачи периодической информации, когда следующий отсчёт обесценивает предыдущий, TCP тупо вреден.
Кстати, это хорошо понимают люди, которые разрабатывают голосовые и видео протоколы реального времени. Если кадр N+1 пришёл, то кадр N тупо не нужен, а следовательно не нужен и TCP.
Вы правы. То есть, конечно, можно и сеть резервировать, но никто этого дома делать не будет. Тут плюсом является тот факт, что отказ локалки пользователь так и так заметит по другим признакам и ситуацию будет исправлять. А отказ брокера или компа под ним, поверьте, можно не видеть месяцами. Из практики.
Мы с Вами рассуждали совершенно идентично и пришли к почти идентичной модели. :) Мультикаст я тоже рассматривал, но пока отложил просто потому, что хотелось обеспечить реализацию для популярных в смарт хоум языков, а что там с мультикастом — навскидку неочевидно. Я вон в lua до обычного UDP-то не достучался. :)
Даже при невероятной тысяче датчиков в квартире и отправке данных раз в секунду этот потолок недостижим. Так что, в целом, надеюсь выжить.
И ещё. При дроп рейте пакетов порядка нескольких процентов TCP встаёт колом и не работает. Для датчика температуры потеря каждого второго отсчёта (дроп рейт 50%) несущественна.
Понятие надёжности ценно осознавать в прикладном аспекте, а не в абстрактном. В реальной свитчованной сети при отсутствии перегрузки по трафику вообще неясно, как UDP пакет может пропасть. Перегрузки по трафику для этой группы узлов быть не может (ок, всё может быть, но видимой причины нет).
При перегрузке и потере пакетов любой TCP протокол ляжет, а UDP будет прорываться, хоть и с кровью.
Нету коллизий в реальной сети. Не с чего им быть. Во-первых, потому что она давно не шина, а свитч, причём store/forward, во-вторых потому что для коллизий нужен довольно серьёзный трафик, которому в сегменте умного дома браться не откуда, и, наконец, потому что проведённые тесты вообще не показали пропаданий пакетов. На вполне живой сети в которой живут три десятка хостов, включая телевизоры, которые сигнал получают только через сеть, и никак иначе.
Типовой масштаб сети — квартира. Для CAN это многовато. Да и локалка в квартире уже есть. И устройства с ethernet/wifi вполне массовые. И стоят уже.
Арбитраж CAN мало чем отличается от арбитража ethernet, а с подтверждением доставки проблема логическая, а не техническая. Сделать его банально, но мы, строго говоря, не знаем количество получателей и не уверены в том, что они работают постоянно.
Хранить на каждом передатчике карту получателей, собирать подтверждения, увеличить в разы трафик в сети, поднять требования к передатчику. Зачем? Датчик температуры всё равно отправит свою температуру через минуту снова.
Можно ещё проще — каждый отправитель раз в N секунд отправляет апдейт своего состояния.
Но, в принципе, меня больше всего волнуют именно датчики, а с ними всё и так хорошо. Выключатели я пока на этот протокол вешать не планирую. Правда, не из соображений надёжности, а просто потому, что они уже сделаны другим способом и реально бродкастить их на всю сеть нет потребности.
А вот датчики температуры — есть потребность отдавать в несколько мест.
Первый — ждать одного подтверждения, и исходить из того, что в современной сети шанс, что один получил, а остальные нет практически нулевой.
Второй — ждать столько же подтверждений, сколько было к предыдущему пакету. Но тут сразу столько вопросов, что ну его нафиг.
Есть промежуточный вариант. Ждать одного подтверждения, но при QoS 2 и подтверждение имеет QoS, причём для каждого получателя в конфигурации указывается максимальный QoS. Например, настенный индикатор вообще на QoS не реагирует и подтверждений не отправляет. Уровень 0. БД хранения истории шлёт подтверждения только на пакеты с QoS 1. А основной процессор событий отвечает с QoS 2. Тогда и отправителям можно выставить уровни важности, и каждый из них будет дожидаться подтверждения от получателя своего уровня важности. Остальные получатели — по остаточному принципу.
Мало того, можно 9 пакетов слать без QoS, а 10-й — с высоким уровнем.
Я к этой схеме склоняюсь.
Но большинство каналов у меня в квартире — именно датчики. Только прямых аналоговых входов pt1000 порядка двадцати.
Кстати, смысл QoS в обычном MQTT от меня ускользает. Если TCP работает, то доставка гарантирована и так. Если не работает, то какие биты в пакете не выставляй — всё прахом.
По деньгам — сложно сказать. Вряд ли меньше ста т.р., вряд ли больше 200.
«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 хоть что-то сделал просто. :)
Предложенный Вами тест не имеет смысла. Если производительность свитча не упёрлась в полку, то две пары портов будут работать на полной скорости параллельно вообще не мешая друг другу.
Ну и да, я пробовал. :) Я пока умозрительно не вижу ситуации, в которой бы UDP начал терять 100% пакетов, а TCP работал бы. Вижу ситуацию, в которой TCP лежит, а UDP доносит половину.
Ну и практические ситуации, когда DNS работает, а HTTP не бегает мне тоже вполне встречались. Именно что когда дроп рейт становится ощутим. Даже при 10% потери пакетов TCP не жилец в реальности.
Вы как-то религиозно упираетесь в «защищённость» TCP — у неё есть своя применимость и свой порог осмысленности. Для передачи периодической информации, когда следующий отсчёт обесценивает предыдущий, TCP тупо вреден.
Кстати, это хорошо понимают люди, которые разрабатывают голосовые и видео протоколы реального времени. Если кадр N+1 пришёл, то кадр N тупо не нужен, а следовательно не нужен и TCP.
PID-регуляторы в итоге писал сам, это оказалось проще, чем постичь штатные, да и легче было сделать связанный алгоритм руления полом и радиаторами.
И ещё. При дроп рейте пакетов порядка нескольких процентов TCP встаёт колом и не работает. Для датчика температуры потеря каждого второго отсчёта (дроп рейт 50%) несущественна.
Понятие надёжности ценно осознавать в прикладном аспекте, а не в абстрактном. В реальной свитчованной сети при отсутствии перегрузки по трафику вообще неясно, как UDP пакет может пропасть. Перегрузки по трафику для этой группы узлов быть не может (ок, всё может быть, но видимой причины нет).
При перегрузке и потере пакетов любой TCP протокол ляжет, а UDP будет прорываться, хоть и с кровью.
Внезапно, UDP… надёжнее для этого применения.
— Можно сделать дома холодный резерв. Но ЗАЧЕМ? И — кто будет следить за тем, что он готов и работает? И кто будет управлять реле? По какому признаку?
И, главное, цель-то в чём такого усложнения?
Арбитраж CAN мало чем отличается от арбитража ethernet, а с подтверждением доставки проблема логическая, а не техническая. Сделать его банально, но мы, строго говоря, не знаем количество получателей и не уверены в том, что они работают постоянно.
Хранить на каждом передатчике карту получателей, собирать подтверждения, увеличить в разы трафик в сети, поднять требования к передатчику. Зачем? Датчик температуры всё равно отправит свою температуру через минуту снова.
Но, в принципе, меня больше всего волнуют именно датчики, а с ними всё и так хорошо. Выключатели я пока на этот протокол вешать не планирую. Правда, не из соображений надёжности, а просто потому, что они уже сделаны другим способом и реально бродкастить их на всю сеть нет потребности.
А вот датчики температуры — есть потребность отдавать в несколько мест.