• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Нужна помощь Micropython ошибка LmacRxBlk:1

evgeny2k

New member
День добрый всем. Пишу многопоточный HTTP сервер и напоролся на проблему. Если одновременно обрабатывается более 3 соединений, то часто вываливается вот такая ошибка в консоль: LmacRxBlk:1
Кто-нибудь сталкивался с подобным? На англоязычных форумах нашел информацию о том, что якобы такое будет случаться в случае попытки открыть более 5 соединений. Но в моём случае бяка проявляется начиная с трёх периодически и от пяти - постоянно. Как лечить? Какие есть мысли? Где грабли?
 

nikolz

Well-known member
День добрый всем. Пишу многопоточный HTTP сервер и напоролся на проблему. Если одновременно обрабатывается более 3 соединений, то часто вываливается вот такая ошибка в консоль: LmacRxBlk:1
Кто-нибудь сталкивался с подобным? На англоязычных форумах нашел информацию о том, что якобы такое будет случаться в случае попытки открыть более 5 соединений. Но в моём случае бяка проявляется начиная с трёх периодически и от пяти - постоянно. Как лечить? Какие есть мысли? Где грабли?
посмотрите здесь есть варианты решения:
LmacRxBlk:1 mess · Issue [HASHTAG]#928[/HASHTAG] · esp8266/Arduino · GitHub
 

evgeny2k

New member
Спасибо за ответ. Эту тему я уже видел. Здесь и написано, что может быть 5 соединений:
its very easy to overload the ESP with all this request.
the maximum of TCP sockets is at 5 and the backlog is at 1.
В моем сервере достаточно стабильно обрабатывается до 3 соединений одновременно. При трёх открытых соединениях иногда (при большом буфере ~512) можно поймать эту ошибку. При 4 соединениях ошибка проявляется уже значительно чаще, но не всегда. При 5 и более соединений - 100% появление ошибки. Что интересно, этот же сервер на micropython под linux работает как пулемет и обрабатывает 160 одновременных соединений совершенно без проблем. Думаю, и большее количество будет прекрасно обработано, но проверять лень. Проблема похоже зарыта именно в реализации сокетов. По части контроля используемой памяти у меня тоже есть блокировочки и сервер не будет запускать новые процессы при исчерпании отведенного ему лимита. Т.е. на момент появления ошибки всегда имеется достаточное количество памяти.
 

nikolz

Well-known member
Спасибо за ответ. Эту тему я уже видел. Здесь и написано, что может быть 5 соединений:
its very easy to overload the ESP with all this request.
the maximum of TCP sockets is at 5 and the backlog is at 1.
В моем сервере достаточно стабильно обрабатывается до 3 соединений одновременно. При трёх открытых соединениях иногда (при большом буфере ~512) можно поймать эту ошибку. При 4 соединениях ошибка проявляется уже значительно чаще, но не всегда. При 5 и более соединений - 100% появление ошибки. Что интересно, этот же сервер на micropython под linux работает как пулемет и обрабатывает 160 одновременных соединений совершенно без проблем. Думаю, и большее количество будет прекрасно обработано, но проверять лень. Проблема похоже зарыта именно в реализации сокетов. По части контроля используемой памяти у меня тоже есть блокировочки и сервер не будет запускать новые процессы при исчерпании отведенного ему лимита. Т.е. на момент появления ошибки всегда имеется достаточное количество памяти.
Как я понял, там еще написано, что в очередь может стоять лишь одно. Т е если у Вас в момент обработки еще пришли два т е всего три то будет кирдык.
 

evgeny2k

New member
Сейчас количество прослушиваемых сокетов = количеству потоков. Вот пример : self.socket.listen(self.maxthreads) Т.е. появилось соединение - сразу ушло в поток в обработку (
socket.accept() и дальше передача сокета в обрабатывающую ф-ию). Пришел запрос от клиента на новое соединение, но в этот момент лимит потоков/сокетов исчерпан - клиент получил отказ (socket.accept() для него не выполняется). Сокет разумеется в неблокирующем режиме. В итоге получается, что в очереди вроде как никто и не стоит. Хотя на низком уровне конечно всегда имеем очередь запросов.
 
Сверху Снизу