Hello,
When you call 'httpc_get_file' the parameter 'connection' gives you a
handle on the http_state used for that connection
then you can passes this handle to 'httpc_get_file' via the parameter
'void * callback_arg'
then your received function will get the handle via the parameter 'void * arg'
then in the received function you can do (http_state_t
*)arg->timeout_ticks = MY_RELOAD_VALUE;
http_state_t * foo;
httpc_get_file(ip, port, uri, settings, my_recv_fn, foo, &foo)
err_t my_recv_fn(void * arg, ...)
{
(http_state_t *)arg->timeout_ticks = MY_RELOAD_VALUE;
}
You might have a compilation issue because 'http_state_t' is normally
an opaque type for the application then the member 'timeout_ticks' is
not visible from the application.
In a past project I solved that by exporting the definition of
'http_state_t' but maybe this is already fixed in the last release of
lwip.
Regards
Rémy
Le mer. 16 juin 2021 à 13:24, Bas Prins <bas.pri...@gmail.com> a écrit :
>
> Dear ,
>
> I don't think I am able to reset the timer. The 'arg' passed in
>
> err_t rec_fn(void *arg, struct altcp_pcb *conn, struct pbuf *p, err_t err)
>
> is not of type httpc_state_t. The rec_fn callback is called here:
>
> static err_t
> httpc_tcp_recv(void *arg, struct altcp_pcb *pcb, struct pbuf *p, err_t r)
> ...
> ...
> ...
> if (req->recv_fn != NULL) {
> /* directly return here: the connection migth already be aborted from
> the callback! */
> return req->recv_fn(req->callback_arg, pcb, p, r);
> }
>
> So what's the deal with this function
>
> /** http client tcp poll callback */
> static err_t
> httpc_tcp_poll(void *arg, struct altcp_pcb *pcb)
> {
> /* implement timeout */
> httpc_state_t* req = (httpc_state_t*)arg;
> LWIP_UNUSED_ARG(pcb);
> if (req != NULL) {
> if (req->timeout_ticks) {
> req->timeout_ticks--;
> }
> if (!req->timeout_ticks) {
> return httpc_close(req, HTTPC_RESULT_ERR_TIMEOUT, 0, ERR_OK);
> }
> }
> return ERR_OK;
> }
>
> It only decreases the ticks counter. It never gets reset. So I am not allowed
> to download files longer than 30 secs? If the download doesn't succeed within
> that time, http_client closes the connection.
>
> I would expect that either the timeout counter is reset every chunk of data
> which is received, or that user code (my code) would receive a pointer to the
> httpc_state_t so that it could reset the timer.
>
> Can somebody please explain where I am wrong, what am I missing, or that
> indeed the current implementation of http_client is lacking ?
>
> Many thanks in advance
>
> best regards, bas
>
>
>
> Op wo 16 jun. 2021 om 09:29 schreef Bas Prins <bas.pri...@gmail.com>:
>>
>> Hi all,
>>
>> I found the problem, which was rather easy to find once I convinced myself I
>> am man enough to actually read code ;-).
>>
>> But now I wonder how to solve this appropriately. The problem seems to be,
>> that this function decreases the ticks, until the timeout period is
>> consumed, and then simply closes the connection.
>>
>> /** http client tcp poll callback */
>> static err_t
>> httpc_tcp_poll(void *arg, struct altcp_pcb *pcb)
>> {
>> /* implement timeout */
>> httpc_state_t* req = (httpc_state_t*)arg;
>> LWIP_UNUSED_ARG(pcb);
>> if (req != NULL) {
>> if (req->timeout_ticks) {
>> req->timeout_ticks--;
>> }
>> if (!req->timeout_ticks) {
>> return httpc_close(req, HTTPC_RESULT_ERR_TIMEOUT, 0, ERR_OK);
>> }
>> }
>> return ERR_OK;
>> }
>>
>> So I wonder, who should be responsible for resetting the timeout counter? My
>> code? The definition of the timeout_ticks seems to only visible for to
>> http_client.c.
>>
>> If I simply comment the line which decreases the counter the download works.
>>
>> Am I still missing the obvious here?
>>
>> Many thanks.
>>
>> best regards, bas
>>
>> Op ma 14 jun. 2021 om 22:05 schreef Bas Prins <bas.pri...@gmail.com>:
>>>
>>> Hi Simon, all,
>>>
>>> Fixed the problems I had which led to missing a byte occasionally.
>>>
>>> Still unable to download a file using http_client.h. I did learn a small
>>> part. I log all arguments of
>>>
>>> void result_fn(void *arg, httpc_result_t httpc_result, u32_t
>>> rx_content_len, u32_t srv_res, err_t err)
>>>
>>> Which produces this log line:
>>> 2021-06-14 21:31:52,041 [DEBUG][thread: 5][UartReader] DOWNLOAD finished:
>>> httpc_result=5, rx_content_len=5019, srv_res=0, error=0
>>>
>>> /** Connection timed out (server didn't respond in time) */
>>> HTTPC_RESULT_ERR_TIMEOUT = 5,
>>>
>>> I attached the pcap file of tcpdump.
>>> - It contains a couple of attempts to download the file (513KB.zip).
>>> - It shows TCP window full warnings. I don't care too much about that now.
>>> I'll deal with that once I have a stable download going.
>>> - It shows the result of the timeout where my STM board closes the
>>> connection.
>>>
>>> I also attached my lwipopts.h and the loggings produced by my app
>>> (including lwip ppp logging).
>>>
>>> Can you help me understand what is going wrong?
>>> Why is LWIP complaining about the server not responding in time, while it
>>> seems that the server is doing just fine?
>>>
>>> PS: obviously I tested the download on my desktop, I am able to download
>>> the file repeatedly.
>>>
>>> Many thanks in advance!
>>>
>>> Best regards, Bas
>>>
>>>
>>> Op vr 11 jun. 2021 om 07:15 schreef goldsi...@gmx.de <goldsi...@gmx.de>:
>>>>
>>>> Am 10.06.2021 um 17:27 schrieb Bas Prins:
>>>> > Hi Simon,
>>>> >
>>>> > Thanks, that's a very likely explanation already. I just added the
>>>> > pbuf_free(p) but run into an assert occasionally.
>>>>
>>>> You might have to check for 'p != NULL' just like in tcp recv callback
>>>> functions.
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>>> _______________________________________________
>>>> 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
