On Tue, Apr 28, 2015 at 09:17:54AM +0200, Daniel Stenberg wrote:
> There are some outstanding questions, like if we should do this by
> default without any options to ask for it and if we really should
> forcibly limit the number of connections to the same host to one.
> And I'm sure there will pop up a few more questions going forwarwd.

Limiting the number of connections to one per-multi handle has a nice
property that it's predictable and gets libcurl out of the business of
having to pick a connection optimally. The downside of that is that it
gets the application into that business, when it could just have been
libcurl.

> Right now I use CURLMOPT_PIPELINING as a signal to activate
> multiplexing. I think this is fine for now, but I also imagine that
> there are users who'd like HTTP/2 multiplexing but not HTTP/1.1
> pipelining so they'd have to use different bits if so...

Yes, probably!

Just add CURLMOPT_MULTIPLEXING, no?

> Right now I need CURLMOPT_MAX_HOST_CONNECTIONS set to 1 to really
> stay on one connection only, and again, this may be fine for
> HTTP/2-only users but it may not be what users want for all
> protocols at once. Not sure how to handle this, but I'm not entirely
> happy with this and neither would I be to add a totally option like
> CURLMOPT_MAX_HOST_HTTP2_CONNECTIONS for this specific protocol
> version.

Multiple connections -> load balancing between them. Which is fine, but
probably hard to get right. If the application knows how to get it
right, let it multiple across multiple multi handles. Otherwise let
libcurl load balance as it wishes.

Using multiple multi handles with one event loop has to be easy though.
(I've never tried it. But looking at the API it looks easy enough.)

Nico

-- 
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html