esp32c3 - Мутная работа с WiFi

[pvvx]

есть ограничения на мктт-ехплорере, но точно не помню, то ли 500 на топик, то ли 5000 на топик, то ли 5000 на все
вообще, бывают какие-то сбои на мктт-брокере (ну или еще вокруг него):

MQTT работает т через TCP-IP. Стоит проверить лог TCP-IP, к примеру, в Wireshark.

Если у вас ESP засыпает и снова соединяется, тогда номер порта для соединения выбирается по псевдо-рандом, а IP фиксирован. И номер порта может совпадать с прошлым закрытым соединением.

По стандарту в TCP-IP, сторона закрывшая соединение, должна выдержать 120 секунд для всех следующих запросов соединений по использованным IP и порту адресата и получателя. В этот период всем поступившим пакетам типично дается команда закрытия соединения (break)...

ИИ: Интервал TIME_WAIT — это обязательное состояние TCP-соединения.
Оно гарантирует, что все потерянные пакеты дойдут до адресата, и предотвращает смешивание старых и новых данных при повторном использовании тех же IP-адресов и портов.

В итоге некоторые соединения от EPS будут откинуты сервером и промежуточным сетевым оборудованием. При несоблюдении данного стандарта (TIME_WAIT) будут происходить проблемы по цепочке сетевых устройств (роутеров, NAT и т.д.)…

 

[pvvx]

вообще, бывают какие-то сбои на мктт-брокере (ну или еще вокруг него)

Спецификация RFC подразумевает, что локальный сокет должен оставаться активным в состоянии TIME_WAIT в течении 2xMSL.
MSL - это максимальное время жизни сегмента. RFC задает MSL как 120 секунд. Т.е. стандартное время ожидания в TIME_WAIT равно 4 минутам.
Всякие ухищрения и сокращения этого интервала = уход от стандарта TCP/IP на отсебятенный стандрат (на урезанную реализацию TCP в ESP).
Так что проверяйте, что там творится в сети у вашего MQTT сервера…
Или не делайте разрывов TCP соединений и всяких снов в ESP используя keepalive соединение...

 

[pvvx]

у меня контроллер сначала связывается с брокером, лезет в ветку с мак-адресами, по мак-адресу получает имя и уже под этим именем публикует данные. так вот, на периоде пары-тройки суток, это порядка тысячи коннектов, контроллер не получает имени и публикует несколько сообщений безымянными, просто под своим мак-адресом. мак-адреса и имена прописаны в брокере как сообщения с ретейн-аттрибутом

Это и похоже на повторное использование соединения с закрытыми IP/портами прошлого соединения находящегося в TIME_WAIT, если на каждый запрос на MQTT создаете новое TCP соединение. Первый запрос отбрасывается по TIME_WAIT, а следующий уже идет с новым номером порта…