IBAH (02.11.2024 21:54, просмотров: 52) ответил framer на Первый раз onload вызывается когда инстанцируется обект фрейма в
DOM. Второй раз когда идет загрузка документа после операции
src='хххх.htm'-
- получается чтото похожее на рекурсивный вызов. По идеии ниже то что
пробуете сделать framer(658 знак., 02.11.2024 21:57)
- Победил!!! надо так. Только непонятно где правильно ставить <script> f=0; </script> ? Поставил по наитию, в заголовке перед
боди IBAH(814 знак., 02.11.2024 22:29)
- Аааа так Вам надо, чтобы не было паралельной загрузки. Наверное
появятся проблемы в другом месте. А как с загрузкой рисунков, css и
других жабасриптов? По идеи если есть только одно соединение, то
остальные должны ожидать. Т.е не париться с кодом и дизайном
страничек только проблему решить на стороне сервера. - framer(02.11.2024 23:35)
- Сервер на МК. Каждый сокет на вес золота. Рисунки через Base64,
скриптов нам не надо. Фреймы нужны для того, чтобы всю толстую
страничку хранить во флеше, а маленький фрейм в ОЗУ. Проблему
многосокетности я описал в соседней ветке. IBAH(1 знак., 02.11.2024 23:50, ссылка)
- Неужели для 8266 нет сносного стека тсп? ASDFS(62 знак., 03.11.2024 01:25)
- Да выглядит, что стек не очень и это не зависит от количества доступных сокетов. В нормалном стеке с огрничением сокетов выглядит вот так. Если не хватает сокетов то на SYNC клиента сервер не отвечает а клиент делает ретрансмисию через определенное время. Как только на стороне сервера появляется свободный сокет, то сервер дает ACK. Както вот так. framer(363 знак., 03.11.2024 14:12, картинка)
- Сколько ОЗУ вы бы отдали одному сокету? Всего у 8266 около 50к ОЗУ
на всё. - AlexBi(03.11.2024 09:11)
- В PIC18F67J60 и 4к нет. А у меня там десяток сокетов крутилось. ASDFS(103 знак., 03.11.2024 13:58)
- 8266 выделяет только по 2048 на буфера приема-передачи, итого на 5
сокетов 5*2*2048=20кб - IBAH(03.11.2024 14:31)
- Об чем и речь, на кой там каждому сокету свои буфера в ОЗУ когда достаточно ASDFS(201 знак., 03.11.2024 14:59)
- lwip выделяет только sizeof(struct tcp_pcb) - у меня это 160 байт - SciFi(03.11.2024 14:39)
- 8266 выделяет только по 2048 на буфера приема-передачи, итого на 5
сокетов 5*2*2048=20кб - IBAH(03.11.2024 14:31)
- В PIC18F67J60 и 4к нет. А у меня там десяток сокетов крутилось. ASDFS(103 знак., 03.11.2024 13:58)
- Неужели для 8266 нет сносного стека тсп? ASDFS(62 знак., 03.11.2024 01:25)
- Сервер на МК. Каждый сокет на вес золота. Рисунки через Base64,
скриптов нам не надо. Фреймы нужны для того, чтобы всю толстую
страничку хранить во флеше, а маленький фрейм в ОЗУ. Проблему
многосокетности я описал в соседней ветке. IBAH(1 знак., 02.11.2024 23:50, ссылка)
- <script> f=0; </script> будет в самом начале. - framer(02.11.2024 22:30)
- Так внутри <head> или внутри <body> ? - IBAH(02.11.2024 22:36)
- при стандартном подходе жабастрипты помещают в head - framer(02.11.2024 22:42)
- На такие вопросы гугел хорошо отвечает. - SciFi(02.11.2024 22:41)
- С живым человеком завсегда приятнее поговорить. - IBAH(02.11.2024 23:00)
- Так внутри <head> или внутри <body> ? - IBAH(02.11.2024 22:36)
- Аааа так Вам надо, чтобы не было паралельной загрузки. Наверное
появятся проблемы в другом месте. А как с загрузкой рисунков, css и
других жабасриптов? По идеи если есть только одно соединение, то
остальные должны ожидать. Т.е не париться с кодом и дизайном
страничек только проблему решить на стороне сервера. - framer(02.11.2024 23:35)
- Победил!!! надо так. Только непонятно где правильно ставить <script> f=0; </script> ? Поставил по наитию, в заголовке перед
боди IBAH(814 знак., 02.11.2024 22:29)
- получается чтото похожее на рекурсивный вызов. По идеии ниже то что
пробуете сделать framer(658 знак., 02.11.2024 21:57)
