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.
Re: libcurl SSL session reuse & connection reuse
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 13 Nov 2020 15:53:07 +0100 (CET)
On Fri, 13 Nov 2020, Alen Loncaric wrote:
> So what the lib is missing is here you have a shared object but use only
> SSL ticket
> Or having an option on curl object to do something like
> easy_close_current_connection(curl obj)
I don't think I still quite understand what you're asking for, but I also
suspect it doesn't matter too much! =)
> Also this would be ok as if we leave maxage to 118sec and use connection
> cache, the connection does not get closed until next curl operation is done,
> which can be 1 hour away.
Why does this matter? A connection that is left (unused) in the connection
cache for longer than maxage seconds will not be considered for reuse but yes
it will remain there until curl has a reason to traverse the pool again. And
then it will be killed off if determined too old.
> And my understanding is that this max age connection will not disconnect as
> there is no housekeeping after the 118s, meaning that we will be connected
> to the server until next operation.
If nothing closes the connection, it will remain open indeed. But libcurl will
never use it again.
> So for this reasons something like easy_close_current_connection(curl obj)
> would be perfect. Or adding a function check for max age connections, which
> we can manually call to do housekeeping.
Why is it a concern for you if curl doesn't kill the connection sooner? It
feel like you are putting a little more meaning into having that connection
than what seems reasonable.
And regarding a function check for maxage connections, we could probably
consider adding such a check to curl_easy_upkeep(). To me that seems like it
would be within its realms and not too much of a stretch.
We've also had this entry in the TODO for a while already:
https://curl.se/docs/todo.html#Offer_API_to_flush_the_connectio
> p.s. also extracting SSL session and loading it into shared object would
> come in handy...
I believe that's an even older TODO entry:
https://curl.se/docs/todo.html#Export_session_ids
Date: Fri, 13 Nov 2020 15:53:07 +0100 (CET)
On Fri, 13 Nov 2020, Alen Loncaric wrote:
> So what the lib is missing is here you have a shared object but use only
> SSL ticket
> Or having an option on curl object to do something like
> easy_close_current_connection(curl obj)
I don't think I still quite understand what you're asking for, but I also
suspect it doesn't matter too much! =)
> Also this would be ok as if we leave maxage to 118sec and use connection
> cache, the connection does not get closed until next curl operation is done,
> which can be 1 hour away.
Why does this matter? A connection that is left (unused) in the connection
cache for longer than maxage seconds will not be considered for reuse but yes
it will remain there until curl has a reason to traverse the pool again. And
then it will be killed off if determined too old.
> And my understanding is that this max age connection will not disconnect as
> there is no housekeeping after the 118s, meaning that we will be connected
> to the server until next operation.
If nothing closes the connection, it will remain open indeed. But libcurl will
never use it again.
> So for this reasons something like easy_close_current_connection(curl obj)
> would be perfect. Or adding a function check for max age connections, which
> we can manually call to do housekeeping.
Why is it a concern for you if curl doesn't kill the connection sooner? It
feel like you are putting a little more meaning into having that connection
than what seems reasonable.
And regarding a function check for maxage connections, we could probably
consider adding such a check to curl_easy_upkeep(). To me that seems like it
would be within its realms and not too much of a stretch.
We've also had this entry in the TODO for a while already:
https://curl.se/docs/todo.html#Offer_API_to_flush_the_connectio
> p.s. also extracting SSL session and loading it into shared object would
> come in handy...
I believe that's an even older TODO entry:
https://curl.se/docs/todo.html#Export_session_ids
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2020-11-13