> I think our primary focus should be to solve the problem for when libcurl is > actually still doing transfers, just not over one of the connections in the > connection cache. Like perhaps as I mention above. > The slightly different problem is how to handle a libcurl handle that holds a > number of connections in its pool which you want to keep alive but you're not > doing any libcurl transfers at all so there's no reason to call libcurl. I > think we perhaps should consider adding some new API or similar for this, > that lets the app regularly tell curl to keep things alive. It could then be > merged into the app's main loop for when there's no active transfers going > on. Like a "null transfer" mode. > All this said, I don't have a predetermined design envisioned for this. I'm > open for other ideas or approaches!
I'm now thinking about the "sending HTTP/2 PINGs" part of this code. My sketch design for this is as follows: * Add a new top level API for curl_easy and curl_multi which does the "null transfer" mode above. Named appropriately for something which doesn't do a transfer, but checks to make sure things on that handle are still ok. (curl_easy_housekeeping?). * Make that function iterate over the connections in its connection cache, and build on the code in my other fix (https://github.com/curl/curl/pull/1521) to perform a "KEEPALIVE" check on those protocols with connection check callbacks. It could also clean up dead connections as well? * The HTTP/2 callback would keep a track of how long it had been since the connection had been kept-alive, and whether it should send an HTTP/2 PING or not. If it should, it uses nghttp2 to create and send a PING. One question would be whether to make the HTTP/2 PING keepalive timeout configurable - if so, we'd have to store that using a CURLOPT/CURLMOPT. Thoughts? ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
