Does nobody have the time to give me some advise where the problem could
be ?
Any help would really be very welcome.
Kind regards
Roland
Am 17.09.24 um 09:32 schrieb Info via lwip-users:
Hi
I got a step further with my investigation. The "delayed" answer is
related to the TCP_TMR_INTERVAL, it is set to 250 ms. If I set this
value to 100ms for example, the answer from the web server is sent
faster (means after about 100 ms the answer is received).
I have attached three Wireshark capture showing the communication of
different settings:
HTTPD_answer _in_CGI_handler :
The answer file is completly created in the CGI handler (which is
more or less our answer timing reference)
HTTPD_async_read_250ms_tcp_timer :
The answer file is available after the helper task has been running
(calling tcpip_callback() at the end) and TCP_TMR_INTERVAL is set to 250
HTTPD_async_read_100ms_tcp_timer :
The answer file is available after the helper task has been running
(calling tcpip_callback() at the end) and TCP_TMR_INTERVAL is set to 100
Lowering TCP_TMR_INTERVAL could help, but I'm not sure if this is the
correct way ?
Maybe I missed something before calling tcpip_callback(), which calls
http_continue() (the callback function and arguments passed by
fs_read_async() ).
Any help or tips are welcome.
Kind regards,
Roland
Am 13.09.24 um 15:35 schrieb Info via lwip-users:
Hi
I'm using the web server (httpd) from the lwIP (V2.13) with FreeRTOS.
The web server is running fine so far. A socket server is also
running (in it's own task) to implement a small command line. The web
server also has the ability to access the command line over HTTP
requests. Both the web and the socket server using the same command
line parser functionality. The parser is protected with a semaphore,
because not all commands on the command line are fully reentrant.
Problem: If both the socket and the web server using the parser at
the same time a deadlock could occurs, that is because the web server
is running in the TCP task context and the socket server is trying to
use the TCP task from inside the command line parser.
I enabled the LWIP_HTTPD_FS_ASYNC_READ and it's functionality and
added the required code. The CGI handler now creates an empty
response file and sends a message to the helper task. The helper task
receives the message, calls the command line parser and initiate to
send back the answer via a tcpip_callback() call.
With this implementation, it is possible to call the command line
parser outside of the TCP task context and not blocking the TCP task.
That works so far, but the answer time of this solution is 10 times
slower, than to call the command line parser directly in the CGI
handler. I measured the time between the receive of the HTTP request
and the call of the callback function passed by tcpip_callback() and
that is not the problem. It is something in the lwIP that slow down
the answer.
Question:
- What could be the reason of the longer response time (about 250ms
instead of 20ms) ?
- Is it possible to let the web server (httpd) in it's own task ? Has
anyone done it already ?
Thank you very much for your help.
Regards, Roland
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
