>> - 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
Received on 2017-05-30