Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
libcurl multi timeout after IP or routing table changes
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Silas via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 25 Jan 2022 21:24:30 -0300
Hi!
First of all, thanks for such a great tool! libcurl is amazing!
Now the problem... I looked for something about that in the documentation but
couldn't find anything.
I'm using multi interface to keep different connections (not more than 3),
polling it for updates. But, whenever my local IP address change (and also the
routing table), I keep receiving CURLE_OPERATION_TIMEDOUT (28), even though
connection to the rest of the network is fully restablished after IP and route
changing. Removing it (with curl_multi_remove_handle()) and cleaning it up (with
curl_easy_cleanup()) is not enough: the only way to make it work again is to
destroy my multi handler (with curl_multi_cleanup()) and creating it again (with
curl_multi_init()).
Is it expected? Is this documented anywhere? Why is such limitation bound to the
multi handler and not each easy handler?
I can provide you with a small C program and a 2 line shell script (to change
network configuration in a NetBSD or Linux box) to reproduce this behaviour, if
you want.
Thanks!
Date: Tue, 25 Jan 2022 21:24:30 -0300
Hi!
First of all, thanks for such a great tool! libcurl is amazing!
Now the problem... I looked for something about that in the documentation but
couldn't find anything.
I'm using multi interface to keep different connections (not more than 3),
polling it for updates. But, whenever my local IP address change (and also the
routing table), I keep receiving CURLE_OPERATION_TIMEDOUT (28), even though
connection to the rest of the network is fully restablished after IP and route
changing. Removing it (with curl_multi_remove_handle()) and cleaning it up (with
curl_easy_cleanup()) is not enough: the only way to make it work again is to
destroy my multi handler (with curl_multi_cleanup()) and creating it again (with
curl_multi_init()).
Is it expected? Is this documented anywhere? Why is such limitation bound to the
multi handler and not each easy handler?
I can provide you with a small C program and a 2 line shell script (to change
network configuration in a NetBSD or Linux box) to reproduce this behaviour, if
you want.
Thanks!
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-01-26