On Thu, 25 May 2017, Max Dymond via curl-library wrote:
I'm currently using libcurl with the HTTP/2 support, and it's working well
so far. However, I want to be able to support HTTP/2 PING frames for keeping
alive the TCP connection to Apple's Push Notification servers.
Cool. This lack of support has been touch upon in the past too and I think an
improvement in this area would be appreciated by several users. Thanks for
picking up this topic!
- There's no mechanism to send PING frames from libcurl outside of the
context of a request.
Right. This is because there's no mechnism anywhere in libcurl for doing
anything to a connection when there's no ongoing transfer on it. Connections
are put in the "connection cache" when not used for transfers, and there
they're just in a list kept for later retrieval.
- 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!
--
/ daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
