>> - Receiving a PING frame from the server outside of a request causes >> curl to think the connection is dead (when the next request for that >> connection is >> made) and to tear it down. > >Exactly this is what prompted to add the "Monitor connections in the >connection pool" to the TODO document: > > https://curl.haxx.se/docs/todo.html#Monitor_connections_in_the_conne > >A handle that also has a connection pool, should monitor those connections as >well when doing a transfers to that pings can be dealt with properly. And >connections closed by servers due to idleness etc could be closed approprietly >at once. > >> Naively I'm thinking about solving this problem with a per-connection >> thread in libcurl (both to send PING frames and receive any PING >> server frames), but I'm eager to hear if anyone else has thought of a >> different design. > >I think the thread route should be avoided as long as possible. It'll open up >for thread-safety problems (as we don't do libcurl multi-threaded today), the >thread library question, the question on how to scale to thousands of >connections properly and more. > >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!
To solve the first problem (receiving a PING frame when it's not expected), would it be reasonable to borrow the existing approach of RTSP? - Add a flag to handlers which have special handling for determining the death of a connection - Add this flag to RTSP and HTTP/2. - Add a callback function to handlers which can be called to determine whether a connection is dead or not - In url.c:disconnect_if_dead: - replace the existing special case code for RTSP with a check for the flag plus a call of the callback - Set Curl_rtsp_connisdead as the callback function for RTSP. And then to fix the HTTP/2 issue (probably): - Add a callback function for HTTP/2 based off Curl_rtsp_connisdead Thoughts? Would this be unnecessary work if a connection manager is introduced? ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
