Скрыть объявление
На нашем форуме недоступен просмотр изображений для неавторизованных пользователей. Если Вы уже зарегистрированы на нашем форуме, то можете войти. Если у Вас еще нет аккаунта, мы будем рады, если Вы к нам присоединитесь. Зарегистрироваться Вы можете здесь.

RTLHTTPD

Тема в разделе "Realtek - SDK, прошивки и утилиты", создана пользователем sharikov, 11 фев 2017.

  1. sharikov

    sharikov Авторитетный участник сообщества

    Сообщения:
    580
    Симпатии:
    52
    Чтобы вылечить падение по TIME_WAIT надо править lwip. Подсчет количества в списке tcp_tw_pcbs lwip не ведет, соединение убивают когда malloc вернет 0 и то всего 1 штуку. А когда pvPortMalloc возвращает 0 система уже труп - не оживет.
    В 6.3 изменений в tcp_alloc и tcp_kill_timewait по сравнению с 1.4.1 нет.

    Попробую переключить lwip на его встроенный аллокатор.

    ---
    поменял:
    Код (Text):
    1. -#define MEMP_MEM_MALLOC         1
    2. +#define MEMP_MEM_MALLOC         0
    лог httpd отключил, результат:
    Код (Text):
    1. ab -n1000 -c4 http://192.168.1.107/test/test.cgi?len=131072
    2. This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
    3. Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    4. Licensed to The Apache Software Foundation, http://www.apache.org/
    5.  
    6. Benchmarking 192.168.1.107 (be patient)
    7. Completed 100 requests
    8. Completed 200 requests
    9. Completed 300 requests
    10. Completed 400 requests
    11. Completed 500 requests
    12. Completed 600 requests
    13. Completed 700 requests
    14. Completed 800 requests
    15. Completed 900 requests
    16. Completed 1000 requests
    17. Finished 1000 requests
    18.  
    19.  
    20. Server Software:        esp8266-httpd/0.4
    21. Server Hostname:        192.168.1.107
    22. Server Port:            80
    23.  
    24. Document Path:          /test/test.cgi?len=131072
    25. Document Length:        131072 bytes
    26.  
    27. Concurrency Level:      4
    28. Time taken for tests:   70.962 seconds
    29. Complete requests:      1000
    30. Failed requests:        0
    31. Total transferred:      131249000 bytes
    32. HTML transferred:       131072000 bytes
    33. Requests per second:    14.09 [#/sec] (mean)
    34. Time per request:       283.848 [ms] (mean)
    35. Time per request:       70.962 [ms] (mean, across all concurrent requests)
    36. Transfer rate:          1806.22 [Kbytes/sec] received
    37.  
    38. Connection Times (ms)
    39.               min  mean[+/-sd] median   max
    40. Connect:        1    3   1.8      3      17
    41. Processing:   175  280 167.3    272    3892
    42. Waiting:        3    9 112.0      5    3548
    43. Total:        177  284 167.5    275    3897
    44.  
    45. Percentage of the requests served within a certain time (ms)
    46.   50%    275
    47.   66%    286
    48.   75%    291
    49.   80%    296
    50.   90%    308
    51.   95%    336
    52.   98%    371
    53.   99%    394
    54. 100%   3897 (longest request)
     
    Последнее редактирование: 11 апр 2017
  2. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.756
    Симпатии:
    1.284
    Не надо его править, надо править политику HTTPD. Не нужны keep-alive соединения на простом встроенном web. Для этого есть websocket.
    LwIP со статическими буферами - это зло. Во первых меньше памяти остается на задачи, во вторых всегда можно вписать проверку и ограничение списка TIME_WAIT на фиксированное число (убивать старые, если их уже более N штук). Если web работает по спецификации, то проблем с TIME_WAIT нет. Уточняйте настройки. В HTTP первым соединение закрывает клиент и только у него должны быть TIME_WAIT.
    TIME_WAIT у web сервера возникают только при ошибочных соединениях.
    Во вторых у вас ограничено кол-во соединений (при статических буферах LwIP), а это ограничение сервисов... Придется постоянно лезть и править кол-во буферов на каждый проект и по хорошему на RTL871xAF памяти не хватает на более-менее web. 200 кило надо под буфера LwIP для среднего web-сервиса. А при динамике это редко, если он успевает обслуживать запросы и правильно выбрана политика его работы.
    Сейчас-то, в HHTPD, если открыть N страниц браузера, то имеем N*5 открытых keep-alive соединения на дцать секунд. Это изначально больше кол-ва списка буфера активных pcb у LwIP (там всего-то 4..5 шт) :) Вот он и орет - не могу то, не могу сё...
     
    Последнее редактирование: 11 апр 2017
  3. sharikov

    sharikov Авторитетный участник сообщества

    Сообщения:
    580
    Симпатии:
    52
    keep-alive нет уже давно

    Со статическими не будет сюрпризов при работе. С динамическим буферами работает пока не нагрузили а под нагрузкой кучи не хватило и кирдык. Протестировать это трудно.

    Без правки lwip это сделать нельзя: там нужные функции объявлены static. Да и вообще правка sdk при разработке приложения полностью исключается.

    В системе с недостаточным количеством озу ограничение сервисов неизбежно. Хотите нормальный сервер берите openwrt модуль и ставьте туда nginx.
    Под динамику надо добавлять ограничение списка TIME_WAIT в lwip и главное : придумывать сценарии нагрузочного тестирования под каждое приложение чтобы выявить пиковое потребление памяти.
     
  4. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.756
    Симпатии:
    1.284
    Ошибаетесь - пример: активных у нас всего 4-ре-5-ть соединения одновременно. Потоков вообще - один (одно ядро CPU и один канал полудуплекс у передатчика WiF). Если успели обработать запрос по событию его возникновения, то буферов для других соединений вообще не нужно. В HTTPD организация обработки сделана не по событиям, а по таймеру RTOS (практически циклом loop() опроса сокетов по таймерному прерыванию низкого приоритета = Arduino в мозге создателя HTTPD). Это уже накладывает требования в создании буферов умноженных на кол-во пакетов принимаемых за время реакции системы. Это число - к десятке :)
    Уже писал - в описание работы web программный socked не входит (он только вредит там и требует его обслуживания). Слово socked иногда связывают с открытым портом, что не есть совсем верно...
    В итоге выходит не Web-сервер, а кошачий HTTPD. На 100500ГГц CPU и 100500 Гбайт RAM это безразлично, но у нас короткий TCP стек (до 4-х пакетов) и тормозной трафик - 1.8 МБ/сек, а ресурсы SoC позволяют обработать все пакеты по мере их поступления. Т.е. нет никакого смысла в буферизации потоков сокетами, т.к. нужно всего обрабатывать строку или команду длиной не более 256 байт в этих потоках и иметь стек дескрипторов для запросов переменных и отдачи блоками файлов. Итого - один буфер на 4 TCP блока (1500*4 байт).
    Пакет из WiFi поступает в LwIP, он его кидает в стек и вызывает калбак обработчика. Обрабатываете эти принятые байты, и если там переменные или запросы то кидаете их распарсенные в общий стек запросов через функции RTOS. На порт (соединение) у вас есть только текущие состояние и прочие флаги, по ним и формируется пакет передачи ответа (к примеру считывание следующего блока flash с файлом). Это всё в треде LwIP и повторного вхождения там нет. Открылись/закрылись запросы памяти и псё. Какое переполнение, если они ограничены 4*1500 байт и 4..5 активных одновременно? А пользовательский процесс ковыряется в стеке запросов от этой системы, с уже распарсенными по функциям и переменным данными. Скорость реакции web у такой системы не 2 ms как у HTTPD, а предел скорости приема-передачи пакета по WiFi + расстояние для прохождения сигнала и ограниченные ресурсы по использованию RAM (100% лезет в RTL00) :)
     
    Последнее редактирование: 11 апр 2017
  5. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.756
    Симпатии:
    1.284
    Чтобы отослать файл в Web надо всего переключать по калбаку адрес на блок передачи LwIP находящийся в 128 мегабайтном "кеше" Flash. :) Какие нафиг буфера? :) Проблемы с буферами только с переменными. Для них работает websocket. Забудьте о AJAX как об устаревшем подходе. Читайте там
    Альтернативные технологии :)
    А входной самый сложный запрос от клиента в web парсится в итого до сотни бит условий для формирования заголовка ответа и имени файла на отдачу (двух указателей – начала и конца файла в flash) Т.е. открытых буферов как таковых у web нет и никакие сокеты ему не нужны, если только вам нужен тормоз, глюки и борьбу с кошками. :)
    Всю буферизацию потоков производит LwIP. Он для этого и держит стек TCP. :)
    Если ему указан буфер передачи на размер стека TCP в области flash то зачем ему буфера на передачу? При приеме пакета у нас ОДНО ядро CPU и во время обработки выполняется открытие и закрытием RAM буфера. Процесс такой один, следовательно буфер - один.
    Где сложность контроля объемов памяти при такой системе? :)
     
    Последнее редактирование: 11 апр 2017
  6. Creep

    Creep Читатель

    Сообщения:
    57
    Симпатии:
    5
    просвятите нЕуча, что такое
    а еще тут упоминались некие "собаки"... о чем речь?
     
  7. aloika

    aloika Активный участник сообщества

    Сообщения:
    367
    Симпатии:
    25
    Это всё шуточки pvvx'a.
    Просто изначально в html-содержимом этого сервера была страничка с фотографиями кошек. А pvvx заменил фото кошек на фото собак и сказал, что так гораздо лучше будет работать.
    Ну а борьба sharikov'a с кошками имеет глубокий символический смысл, описанный в классической литературе задолго до появления ESP8266 и RTL-модулей:

    ***
    - Позвольте-с вас спросить, почему от вас так отвратительно пахнет?
    Шариков понюхал куртку озабоченно.
    - Ну, что ж, пахнет... известно. По специальности. Вчера котов душили, душили.

    .....

    - Что же вы делаете с этими... с убитыми котами?
    - На польты пойдут, - ответил Шариков, - из них белок будут делать на рабочий кредит.

    ****

    :)
     
  8. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.756
    Симпатии:
    1.284
    Немного не так всё. У ESPHTTPD (c) подразумевает, что кошки должны быть приложены...
    Как только "кошек" уберете, то это выйдет уже другое код и другой (c).
     
  9. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.756
    Симпатии:
    1.284
    @sharikov - когда почините это безобразие?
    apache-jmeter-3.1: 5 thread, period 1 sec, loop 100:
    Снимок1369.gif
    на 38-ом запросе сервер упал. И примерно так-же всегда...
    Я ранее давал HTTP для LwIP RTL00 и пример lwhttpd. С теми-же параметрами:
    Снимок1366.gif
    Снимок1368.gif
    Т.е. 5-ть клиентов на нем в минуту могут открыть 21 256 раз файл главной страницы (354 HTTP соединения в секунду). (Старт с 18.965 секунды - 1500 соединений - стоп 23.181 сек)
    Памяти heap при тесте было меньше, чем в ESPHTTPD (доставлены всякие приложения типа Websocked Client и т.д. + пачка тестов):
    CLK CPU 166666666 Hz
    RAM heap 164344 bytes
    TCM heap 64768 bytes
    Предел вышел 30 одновременно долбящих клиентов и оно через время пишет - каюк heap. TIME_WAIT ограничил до 10. keep-alive включен.
    Наверно возьму за базовый код для Web к RTL...
     

    Вложения:

    Последнее редактирование: 14 апр 2017
  10. sharikov

    sharikov Авторитетный участник сообщества

    Сообщения:
    580
    Симпатии:
    52
    Починю когда вы перестанете выдумывать сказки:
    запрос /test/index.html
    graph.png
    table.png
     
  11. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.756
    Симпатии:
    1.284
    Значит опять что-то поменяли?
    И почему коннект 1..4 ms у вас?
    У вас RLT включен через инет и делаете запрос через VPN или через proxy в 300 км от вас?
    С таким "пингом" Ajax будет ужасен.
     
    Последнее редактирование: 14 апр 2017
  12. sharikov

    sharikov Авторитетный участник сообщества

    Сообщения:
    580
    Симпатии:
    52
    Точка доступа поднята на древнем USB свистке и winXP. USB - автоматически +1ms.
    Машина где измерял работает под Virtualbox. Последний быстродействием не блещет.
    На нормальной точке тестить лень, мне есть еще чем заняться: тут по проекту (на RTL) дедлайн приближается.
     
  13. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.756
    Симпатии:
    1.284
    Т.е. халтурим? Стандарты значит совсем пофиг, решаете затычкой? :)
     
  14. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.756
    Симпатии:
    1.284
    Вот это как можете объяснить?
    Снимок1374.gif
    Кошки-сервер дает команду Connection: close\r\n, клиент по приему Content первым закрывает соединение, как положено. Сервак подтверждает, но заносит pcb в TIME_WAIT. Какого фигу?
    А итоге, через несколько соединений получаем это:
    Снимок1375.gif
    Напомню: TIME_WAIT and its design implications for protocols and scalable client server systems - AsynchronousEvents
    "For a server the golden rule is to always ensure that if a TIME_WAIT needs to occur that it ends up on the client and not the server."
    :) (раскрыть)
    После пересылки “контекста” или любых данных ( к примеру только заголовка ответа) в режиме не keep-alive (и там тоже при договоре о закрытии), сервер должен подождать от клиента подтверждения ответа о приеме ([ACK]), далее ответа о закрытии [FIN,ACK] и только после этого закрыть соединение. Исключение составляет пара случаев, происходящих по причине выхода тайм-аута ожидания приема подтверждения закрытия со стороны клиента (пакет потерялся). Тогда сервер может вообще оборвать соединение. Другой вариант – нерадивые прокси. Они стремятся не оставлять на себе TIME_WAIT. По этому просто не передают от клиента эти пакеты. Для выяснения этих причин и ставиться пользователем значение тишины после последней передачи (можно и уточнить, сделать две – паузы ожидания закрытия и паузы тишины со стороны клиента после последней передачи ему чего-либо). 5 секунд обычно хватает.

    На более серьезном сервере, TIME_WAIT разбирается на локальный и внешний ip и port. Если они (все 4-ре значения) не равны новому открытому соединению, то этот порт на сервере или клиенте может не считаться занятым TIME_WAIT. Но это же надо сравнивать, а все программеры, особо приверженные кошакам, бездельники (от этого и безграмотны) и решают задачу путем уничтожения TIME_WAIT раньше времени для освобождения своего порта. Если им не дать исправленный и дописанный код, они никогда не сдвинуться. Но кода и куда вставить я кошка-писателю не давал – надоело – он плохо врубается и сложно что либо ему разъяснить. Придется вам это проделать :)

    Ещё это:
    Снимок1376.gif
    Кошкам было сложно объединить заголовок с данными и собрать полный первый пакет?
    Далее:
    Снимок1377.gif
    Что - котятам не додают? Беда с буферами - RAM не хватает на 2 полных пакета?
    Ущё:
    Снимок1378.gif
    Зачем передавать не динамический файл "кусочками" в нарезке, да ещё такими "ломтиками"? Чтобы медленнее было?

    Исправляйте эти безобразия....
     
    Последнее редактирование: 17 апр 2017
  15. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.756
    Симпатии:
    1.284
    Портировка моего Web от ESP8266 показывает, что 60 одновременных соединений для RTL00 - это нормально :)
    Больше пока не выходит - тест apache-jmeter-3.1 yt не хочет больше одновременно открывать (видимо запросы успевают отрабатывать закрываться)
    Ставлю:
    Thread 100
    Step 1 sec
    Count 10 (чтобы лог не был большим)
    Получаю (обрезанная версия и-за ограничения размера соо. в движке форума):
    Код (Text):
    1.  
    2. CLK CPU         83333333 Hz
    3. RAM heap        177112 bytes
    4. TCM heap        64768 bytes
    5.  
    6. Disk init: 0 files, addr = 0xde000
    7.  
    8. RTL8195A[Driver]: port switch - port0(wlan2), port1(wlan1)
    9. SoftAP ip: 192.168.4.1
    10. RTL8195A[Driver]: set ssid [******]
    11. RTL8195A[Driver]: start auth to ******
    12. RTL8195A[Driver]: auth success, start assoc
    13. RTL8195A[Driver]: association success(res=1)
    14. RTL8195A[Driver]: set pairwise key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4)
    15. RTL8195A[Driver]: set group key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) keyid:1
    16. Station ip: 192.168.1.122
    17. NetBIOS init, interface 0: 'RTL871X0' 1: 'RTL871X1'
    18. WEB: init port 80
    19. atlwnbns: out 192.168.1.122, 'RTL871X0'
    20. srv[80] 192.168.1.2:42818 [1] listen
    21. srv[80] 192.168.1.2:42818 [1] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    22. srv[80] 192.168.1.2:42819 [2] listen
    23. srv[80] 192.168.1.2:42819 [2] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    24. srv[80] 192.168.1.2:42820 [3] listen
    25. srv[80] 192.168.1.2:42820 [3] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    26. srv[80] 192.168.1.2:42821 [4] listen
    27. srv[80] 192.168.1.2:42821 [4] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    28. srv[80] 192.168.1.2:42822 [5] listen
    29. ......
    30. srv[80] 192.168.1.2:42852 [35] listen
    31. srv[80] 192.168.1.2:42852 [35] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    32. srv[80] 192.168.1.2:42853 [36] listen
    33. srv[80] 192.168.1.2:42853 [36] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    34. ....
    35. srv[80] 192.168.1.2:43420 [58] disconnect
    36. srv[80] 192.168.1.2:43478 [58] listen
    37. srv[80] 192.168.1.2:43478 [58] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    38. srv[80] 192.168.1.2:43479 [59] listen
    39. srv[80] 192.168.1.2:43479 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    40. srv[80] 192.168.1.2:43421 [59] disconnect
    41. srv[80] 192.168.1.2:43480 [59] listen
    42. srv[80] 192.168.1.2:43480 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    43. srv[80] 192.168.1.2:43422 [59] disconnect
    44. srv[80] 192.168.1.2:43423 [58] disconnect
    45. srv[80] 192.168.1.2:43424 [57] disconnect
    46. srv[80] 192.168.1.2:43481 [57] listen
    47. srv[80] 192.168.1.2:43482 [58] listen
    48. srv[80] 192.168.1.2:43481 [58] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    49. srv[80] 192.168.1.2:43483 [59] listen
    50. srv[80] 192.168.1.2:43482 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    51. srv[80] 192.168.1.2:43483 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    52. srv[80] 192.168.1.2:43425 [59] disconnect
    53. srv[80] 192.168.1.2:43484 [59] listen
    54. srv[80] 192.168.1.2:43484 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    55. srv[80] 192.168.1.2:43485 [60] listen
    56. srv[80] 192.168.1.2:43485 [60] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    57. srv[80] 192.168.1.2:43486 [61] listen
    58. srv[80] 192.168.1.2:43486 [61] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    59. srv[80] 192.168.1.2:43426 [61] disconnect
    60. srv[80] 192.168.1.2:43427 [60] disconnect
    61. srv[80] 192.168.1.2:43428 [59] disconnect
    62. srv[80] 192.168.1.2:43487 [59] listen
    63. srv[80] 192.168.1.2:43487 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    64. srv[80] 192.168.1.2:43429 [59] disconnect
    65. srv[80] 192.168.1.2:43488 [59] listen
    66. srv[80] 192.168.1.2:43488 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    67. srv[80] 192.168.1.2:43430 [59] disconnect
    68. srv[80] 192.168.1.2:43431 [58] disconnect
    69. srv[80] 192.168.1.2:43489 [58] listen
    70. srv[80] 192.168.1.2:43489 [58] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    71. .....
    72. srv[80] 192.168.1.2:43798 [20] disconnect
    73. srv[80] 192.168.1.2:43799 [19] disconnect
    74. srv[80] 192.168.1.2:43800 [18] disconnect
    75. srv[80] 192.168.1.2:43801 [17] disconnect
    76. srv[80] 192.168.1.2:43802 [16] disconnect
    77. srv[80] 192.168.1.2:43803 [15] disconnect
    78. srv[80] 192.168.1.2:43804 [14] disconnect
    79. srv[80] 192.168.1.2:43805 [13] disconnect
    80. srv[80] 192.168.1.2:43806 [12] disconnect
    81. srv[80] 192.168.1.2:43807 [11] disconnect
    82. srv[80] 192.168.1.2:43808 [10] disconnect
    83. srv[80] 192.168.1.2:43809 [9] disconnect
    84. srv[80] 192.168.1.2:43810 [8] disconnect
    85. srv[80] 192.168.1.2:43811 [7] disconnect
    86. srv[80] 192.168.1.2:43812 [6] disconnect
    87. srv[80] 192.168.1.2:43813 [5] disconnect
    88. srv[80] 192.168.1.2:43814 [4] disconnect
    89. srv[80] 192.168.1.2:43815 [3] disconnect
    90. srv[80] 192.168.1.2:43816 [2] disconnect
    91. srv[80] 192.168.1.2:43817 [1] disconnect
    92. UDP pcbs:
    93. flg:00  0.0.0.0:137     0.0.0.0:0       recv:0x10014969
    94. flg:04  0.0.0.0:68      0.0.0.0:67      recv:0x1000f6bd
    95. flg:00  0.0.0.0:67      0.0.0.0:0       recv:0x1001456d
    96. flg:00  0.0.0.0:55467   0.0.0.0:0       recv:0x1000ff55
    97. Active PCB states:
    98. none
    99. Listen PCB states:
    100. Port 80|65528   flg:06  tmr:0x10003b40  LISTEN
    101. TIME-WAIT PCB states:
    102. none
    103.  
    LOGUART на 1Mbit/s, и то тормозит с выводом....
    Ставил и 500 одновремннных пользователей :eek:. Тогда иногда ругается драйвер WiFi, что не успевает передавать пакеты (сообщает: потери передачи типа n пакетов в сек...). Тест ещё показывает, что приоритеты в SDK для разных задач участвующих в данном бардаке не правильно настроены. При полной загрузке до низко-приоритетных задач не доходит и возникают накапливаемые сбои... Возможно на 166MHz это уменьшиться, но лучше правильно расставить приоритеты (но пока не до них :) ).

    Шарикову: atlw забита перед тестом, во время теста нажал ENTER. Дырку в логе видно, но у консоли низший приоритет и вывела только тогда, когда освободились процессы LwIP, т.е. в конце (см. лог). Т.е. до этого уровня приоритета (консоли) за время теста не проваливается, а ниже уровень IDLE и в нем подтверждение WDT. WDT управляется в platform_autoconf.h и если надо, вставляйте подтверждение где-то в своей задаче...
    В тесте и работающих WiFi ST+AP Heap был 150 кило - скорее всего он и ограничивает кол-во одновременных соединений на уровне к 60 шт. при минимальном ответе HTTP (в web стоит проверка на heap до 16 кило и новое соединение не делает, если менее).
    Получается, что ESPHTTPD = конкретная помойка.
     

    Вложения:

    Последнее редактирование: 18 апр 2017
    aloika нравится это.
  16. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.756
    Симпатии:
    1.284
    На RTL8711AM
    Код (Text):
    1. srv[80] 192.168.1.2:51234 [98] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    2. srv[80] 192.168.1.2:51235 [99] listen
    3. srv[80] 192.168.1.2:51235 [99] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    4. srv[80] new listen - max connection!
    5. srv[80] new listen - max connection!
    6. srv[80] new listen - max connection!
    7. srv[80] new listen - max connection!
    99 одновременных при 300 user... Счас сниму ограничение в 99 сокетов :)...
    Код (Text):
    1.  
    2. srv[80] 192.168.1.2:53804 [217] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    3. srv[80] 192.168.1.2:53812 [218] listen
    4. srv[80] 192.168.1.2:53812 [218] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    5. srv[80] 192.168.1.2:53805 [219] listen
    6. srv[80] 192.168.1.2:53805 [219] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    7. srv[80] 192.168.1.2:53840 [220] listen
    8. srv[80] 192.168.1.2:53840 [220] read: 177 of252[/] GET f[/] head[195\:200 send: 62 cf252 dis
    9. srv[80] 192.168.1.2:53844 [221] listen
    10. srv[80] 192.168.1.2:53844 [221] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
    11. srv[80] 192.168.1.2:54053 [221] disconnect
    12. srv[80] 192.168.1.2:53680 [220] disconnect
    13. srv[80] 192.168.1.2:53672 [219] disconnect
    219 при 500 пользователях... Это уже более DDoS атаки и не требуется.
    Это значит, что DDoS бесполезен для web-свалочного сервера на RTL8711AM...
    https://upload.wikimedia.org/wikipedia/commons/6/6b/DDoS_video.gif
     
    Последнее редактирование: 18 апр 2017
    Simon и aloika нравится это.
  17. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.756
    Симпатии:
    1.284
    @aloika - мне HTML страницы новые в лом рисовать. А переезд веб свалки на RTL уже произошел. Основные тесты вроде проходит...
     
  18. aloika

    aloika Активный участник сообщества

    Сообщения:
    367
    Симпатии:
    25
    Это очень, очень здорово, просто супер.
    А зачем новые рисовать? Те странички вполне нормальные были. Кому нужно - тот сам себе нарисует для конкретных проектов.
     
  19. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.756
    Симпатии:
    1.284
    Там не нужен хлам от ESP8266 и переменные все другие...
    И пора отказываться от Ajax - оно морально устарело, не перспективно совсем. По тому надо менять концепции, хотя-бы на обмен переменными через websocket и возможно поддержку SSI.
    А у меня пока только болванка web сервера, webfs и ни одной описанной странички для RTL-ов, хотя бы примитивной настройки WiFi.
     
    Последнее редактирование: 20 апр 2017
  20. sharikov

    sharikov Авторитетный участник сообщества

    Сообщения:
    580
    Симпатии:
    52
    Три взаимосвязанных обновления в RTLHTTPD:
    1. исправлен бутлоадер (ram_1). теперь осмысленный выбор по gpio какую прошивку загружать
    f28 / rtlhttpd / source / project / src / rtl_boot_s.c — Bitbucket
    2. Webfs объединена с ram_2.p.bin в мульти-сегментный образ.
    3. Новый проект RTL_WEBUPDATER
    f28 / rtl_webupdater — Bitbucket

    По порядку:
    Бутлоадер
    опрашивает 1 или 2 gpio (4 байта с FLASH_SYSTEM_DATA_ADDR + 0x08). Это дает выбор двух или четырех прошивок. gpio переключаются в режим входа с pull-up или pull-down. Если вывод висит в воздухе считается что он в "1" (дефолтное состояние), если замкнут - "0". Дефолтное состояние означает запуск рабочей прошивки, состояния меньше дефолтного - служебные прошивки, 0 - аварийная прошивка (RTL_WEBUPDATER).
    Пример: Задан один вывод 0x11: PB1. Если он висит в воздухе загружается прошивка 1, если PB1 замкнут на землю - прошивка 0 (аварийная). В терминологии Ameba это upgraded Image и default Image соответственно. Для потребителя: при включении питания с нажатой кнопкой "Recovery" устройство загружается в Recovery mode.
    Как стандарт для выбора двух прошивок предлагается PB1. Это Log Uart и толку от него мало а в качестве вывода для выбора прошивки он работает и ничему не мешает.

    Тест выводов выбора прошивки на модуле RTL00:
    pb0 - не работает из-за светодиода в RTL00
    pa1 - не работает pull-up, причина неизвестна (mux?). при подаче лог уровней работает. pull-down работает.
    pa4 - pull-up/down не работает из-за светодиода в модуле RTL00. при подаче лог уровней работает
    pe не проверялся - требуется отключать jtag

    Webfs
    Она теперь объединена с прошивкой ram2.bin как сегмент ROM. Это позволяет прошивать и обновлять бинарник сразу с Websf. Недостаток: нельзя обновить отдельно webfs, но потребителю это не надо а разработчик скрипты держит на внешнем сервере.

    RTL_WEBUPDATER
    Аварийная прошивка которая зашивается как default Image2. Функциональность минимальная чтобы обеспечить Recovery mode. Поднимается открытая AP и пытается подключиться как STATION с ранее сохраненными настройками. Позволяет обновить upgraded Image2 и стереть настройки wi-fi. Автоматически прописывает нужные значения в FLASH_SYSTEM_DATA.
     
    Последнее редактирование: 28 апр 2017
    aloika и Simon нравится это.

Поделиться этой страницей