• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе 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() для него не выполняется). Сокет разумеется в неблокирующем режиме. В итоге получается, что в очереди вроде как никто и не стоит. Хотя на низком уровне конечно всегда имеем очередь запросов.
 
Сверху Снизу