> 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
Received on 2017-06-01