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

RTLHTTPD

sharikov

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

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

---
поменял:
Код:
-#define MEMP_MEM_MALLOC         1
+#define MEMP_MEM_MALLOC         0
лог httpd отключил, результат:
Код:
ab -n1000 -c4 http://192.168.1.107/test/test.cgi?len=131072
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.107 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        esp8266-httpd/0.4
Server Hostname:        192.168.1.107
Server Port:            80

Document Path:          /test/test.cgi?len=131072
Document Length:        131072 bytes

Concurrency Level:      4
Time taken for tests:   70.962 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      131249000 bytes
HTML transferred:       131072000 bytes
Requests per second:    14.09 [#/sec] (mean)
Time per request:       283.848 [ms] (mean)
Time per request:       70.962 [ms] (mean, across all concurrent requests)
Transfer rate:          1806.22 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    3   1.8      3      17
Processing:   175  280 167.3    272    3892
Waiting:        3    9 112.0      5    3548
Total:        177  284 167.5    275    3897

Percentage of the requests served within a certain time (ms)
  50%    275
  66%    286
  75%    291
  80%    296
  90%    308
  95%    336
  98%    371
  99%    394
100%   3897 (longest request)
 
Последнее редактирование:

pvvx

Активный участник сообщества
Чтобы вылечить падение по TIME_WAIT надо править lwip.
Не надо его править, надо править политику 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 шт) :) Вот он и орет - не могу то, не могу сё...
 
Последнее редактирование:

sharikov

Active member
Не надо его править, надо править политику HTTPD. Не нужны keep-alive соединения на простом встроенном web.
keep-alive нет уже давно

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

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

Во вторых у вас ограничено кол-во соединений (при статических буферах LwIP), а это ограничение сервисов...Придется постоянно лезть и править кол-во буферов на каждый проект и по хорошему на RTL871xAF памяти не хватает на более-менее web. 200 кило надо под буфера LwIP для среднего web-сервиса. А при динамике это редко, если он успевает обслуживать запросы и правильно выбрана политика его работы.
В системе с недостаточным количеством озу ограничение сервисов неизбежно. Хотите нормальный сервер берите openwrt модуль и ставьте туда nginx.
Под динамику надо добавлять ограничение списка TIME_WAIT в lwip и главное : придумывать сценарии нагрузочного тестирования под каждое приложение чтобы выявить пиковое потребление памяти.
 

pvvx

Активный участник сообщества
Со статическими не будет сюрпризов при работе. С динамическим буферами работает пока не нагрузили а под нагрузкой кучи не хватило и кирдык. Протестировать это трудно.
Ошибаетесь - пример: активных у нас всего 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) :)
 
Последнее редактирование:

pvvx

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

aloika

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

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

.....

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

****

:)
 

pvvx

Активный участник сообщества
Это всё шуточки pvvx'a.
Просто изначально в html-содержимом этого сервера была страничка с фотографиями кошек. А pvvx заменил фото кошек на фото собак и сказал, что так гораздо лучше будет работать.
Немного не так всё. У ESPHTTPD (c) подразумевает, что кошки должны быть приложены...
Как только "кошек" уберете, то это выйдет уже другое код и другой (c).
 

pvvx

Активный участник сообщества
@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...
 

Вложения

Последнее редактирование:

pvvx

Активный участник сообщества
Починю когда вы перестанете выдумывать сказки:
запрос /test/index.html
Посмотреть вложение 3933
Посмотреть вложение 3934
Значит опять что-то поменяли?
И почему коннект 1..4 ms у вас?
У вас RLT включен через инет и делаете запрос через VPN или через proxy в 300 км от вас?
С таким "пингом" Ajax будет ужасен.
 
Последнее редактирование:

sharikov

Active member
Значит опять что-то поменяли?
И почему коннект 1..4 ms у вас?
Точка доступа поднята на древнем USB свистке и winXP. USB - автоматически +1ms.
Машина где измерял работает под Virtualbox. Последний быстродействием не блещет.
На нормальной точке тестить лень, мне есть еще чем заняться: тут по проекту (на RTL) дедлайн приближается.
 

pvvx

Активный участник сообщества
Вот это как можете объяснить?
Снимок1374.gif
Кошки-сервер дает команду [inline]Connection: close\r\n[/inline], клиент по приему 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
Зачем передавать не динамический файл "кусочками" в нарезке, да ещё такими "ломтиками"? Чтобы медленнее было?

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

pvvx

Активный участник сообщества
Портировка моего Web от ESP8266 показывает, что 60 одновременных соединений для RTL00 - это нормально :)
Больше пока не выходит - тест apache-jmeter-3.1 yt не хочет больше одновременно открывать (видимо запросы успевают отрабатывать закрываться)
Ставлю:
Thread 100
Step 1 sec
Count 10 (чтобы лог не был большим)
Получаю (обрезанная версия и-за ограничения размера соо. в движке форума):
Код:
CLK CPU         83333333 Hz
RAM heap        177112 bytes
TCM heap        64768 bytes

Disk init: 0 files, addr = 0xde000

RTL8195A[Driver]: port switch - port0(wlan2), port1(wlan1)
SoftAP ip: 192.168.4.1
RTL8195A[Driver]: set ssid [******]
RTL8195A[Driver]: start auth to ******
RTL8195A[Driver]: auth success, start assoc
RTL8195A[Driver]: association success(res=1)
RTL8195A[Driver]: set pairwise key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4)
RTL8195A[Driver]: set group key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) keyid:1
Station ip: 192.168.1.122
NetBIOS init, interface 0: 'RTL871X0' 1: 'RTL871X1'
WEB: init port 80
atlwnbns: out 192.168.1.122, 'RTL871X0'
srv[80] 192.168.1.2:42818 [1] listen
srv[80] 192.168.1.2:42818 [1] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:42819 [2] listen
srv[80] 192.168.1.2:42819 [2] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:42820 [3] listen
srv[80] 192.168.1.2:42820 [3] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:42821 [4] listen
srv[80] 192.168.1.2:42821 [4] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:42822 [5] listen
......
srv[80] 192.168.1.2:42852 [35] listen
srv[80] 192.168.1.2:42852 [35] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:42853 [36] listen
srv[80] 192.168.1.2:42853 [36] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
....
srv[80] 192.168.1.2:43420 [58] disconnect
srv[80] 192.168.1.2:43478 [58] listen
srv[80] 192.168.1.2:43478 [58] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:43479 [59] listen
srv[80] 192.168.1.2:43479 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:43421 [59] disconnect
srv[80] 192.168.1.2:43480 [59] listen
srv[80] 192.168.1.2:43480 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:43422 [59] disconnect
srv[80] 192.168.1.2:43423 [58] disconnect
srv[80] 192.168.1.2:43424 [57] disconnect
srv[80] 192.168.1.2:43481 [57] listen
srv[80] 192.168.1.2:43482 [58] listen
srv[80] 192.168.1.2:43481 [58] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:43483 [59] listen
srv[80] 192.168.1.2:43482 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:43483 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:43425 [59] disconnect
srv[80] 192.168.1.2:43484 [59] listen
srv[80] 192.168.1.2:43484 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:43485 [60] listen
srv[80] 192.168.1.2:43485 [60] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:43486 [61] listen
srv[80] 192.168.1.2:43486 [61] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:43426 [61] disconnect
srv[80] 192.168.1.2:43427 [60] disconnect
srv[80] 192.168.1.2:43428 [59] disconnect
srv[80] 192.168.1.2:43487 [59] listen
srv[80] 192.168.1.2:43487 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:43429 [59] disconnect
srv[80] 192.168.1.2:43488 [59] listen
srv[80] 192.168.1.2:43488 [59] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:43430 [59] disconnect
srv[80] 192.168.1.2:43431 [58] disconnect
srv[80] 192.168.1.2:43489 [58] listen
srv[80] 192.168.1.2:43489 [58] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
.....
srv[80] 192.168.1.2:43798 [20] disconnect
srv[80] 192.168.1.2:43799 [19] disconnect
srv[80] 192.168.1.2:43800 [18] disconnect
srv[80] 192.168.1.2:43801 [17] disconnect
srv[80] 192.168.1.2:43802 [16] disconnect
srv[80] 192.168.1.2:43803 [15] disconnect
srv[80] 192.168.1.2:43804 [14] disconnect
srv[80] 192.168.1.2:43805 [13] disconnect
srv[80] 192.168.1.2:43806 [12] disconnect
srv[80] 192.168.1.2:43807 [11] disconnect
srv[80] 192.168.1.2:43808 [10] disconnect
srv[80] 192.168.1.2:43809 [9] disconnect
srv[80] 192.168.1.2:43810 [8] disconnect
srv[80] 192.168.1.2:43811 [7] disconnect
srv[80] 192.168.1.2:43812 [6] disconnect
srv[80] 192.168.1.2:43813 [5] disconnect
srv[80] 192.168.1.2:43814 [4] disconnect
srv[80] 192.168.1.2:43815 [3] disconnect
srv[80] 192.168.1.2:43816 [2] disconnect
srv[80] 192.168.1.2:43817 [1] disconnect
UDP pcbs:
flg:00  0.0.0.0:137     0.0.0.0:0       recv:0x10014969
flg:04  0.0.0.0:68      0.0.0.0:67      recv:0x1000f6bd
flg:00  0.0.0.0:67      0.0.0.0:0       recv:0x1001456d
flg:00  0.0.0.0:55467   0.0.0.0:0       recv:0x1000ff55
Active PCB states:
none
Listen PCB states:
Port 80|65528   flg:06  tmr:0x10003b40  LISTEN
TIME-WAIT PCB states:
none
LOGUART на 1Mbit/s, и то тормозит с выводом....
Ставил и 500 одновремннных пользователей :eek:. Тогда иногда ругается драйвер WiFi, что не успевает передавать пакеты (сообщает: потери передачи типа n пакетов в сек...). Тест ещё показывает, что приоритеты в SDK для разных задач участвующих в данном бардаке не правильно настроены. При полной загрузке до низко-приоритетных задач не доходит и возникают накапливаемые сбои... Возможно на 166MHz это уменьшиться, но лучше правильно расставить приоритеты (но пока не до них :) ).

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

Вложения

Последнее редактирование:

pvvx

Активный участник сообщества
На RTL8711AM
Код:
srv[80] 192.168.1.2:51234 [98] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:51235 [99] listen
srv[80] 192.168.1.2:51235 [99] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] new listen - max connection!
srv[80] new listen - max connection!
srv[80] new listen - max connection!
srv[80] new listen - max connection!
99 одновременных при 300 user... Счас сниму ограничение в 99 сокетов :)...
Код:
srv[80] 192.168.1.2:53804 [217] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:53812 [218] listen
srv[80] 192.168.1.2:53812 [218] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:53805 [219] listen
srv[80] 192.168.1.2:53805 [219] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:53840 [220] listen
srv[80] 192.168.1.2:53840 [220] read: 177 of252[/] GET f[/] head[195\:200 send: 62 cf252 dis
srv[80] 192.168.1.2:53844 [221] listen
srv[80] 192.168.1.2:53844 [221] read: 177 of252[/] GET f[/] head[195]:200 send: 62 cf252 dis
srv[80] 192.168.1.2:54053 [221] disconnect
srv[80] 192.168.1.2:53680 [220] disconnect
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
 
Последнее редактирование:

pvvx

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

aloika

Active member
@aloika - мне HTML страницы новые в лом рисовать. А переезд веб свалки на RTL уже произошел. Основные тесты вроде проходит...
Это очень, очень здорово, просто супер.
А зачем новые рисовать? Те странички вполне нормальные были. Кому нужно - тот сам себе нарисует для конкретных проектов.
 

pvvx

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

sharikov

Active member
Три взаимосвязанных обновления в 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.
 
Последнее редактирование:
Сверху Снизу