On Tue, Dec 17, 2019 at 3:50 PM Daniel Stenberg <[email protected]> wrote:
>
> On Tue, 17 Dec 2019, Kunal Ekawde wrote:
>
> >> Right: CURLMOPT_MAX_CONCURRENT_STREAMS.
>
> > Yes, this is desired behavior, basically that the connection is fully
> > utilized to its multiplexing limit before new one is created towards that
> > host, but I don't see it, rather, it creates new connection to host for a
> > new stream if 'CURLMOPT_MAX_HOST_CONNECTIONS' limit not reached yet.
>
> That's not how the logic in the code works so then something made it not add
> the new transfer to the existing connection first.
>
> libcurl *always* first checks if there's an existing connection it can use for
> the new transfer and if it does, it won't create a new connection.
>
> If there's no connection that is "good enough" (there are quite many rules and
> checks), then it continues and creates a new connection instead.
>
> If there are more than one connection in the cache to select from, then it can
> be a little bit of a hit or miss which one the new request is done over.
>

Ok, here is the example I've verified above behavior with local HTTP/2
server, this is based on http2-download.c example
HTTP/2 transfers are on http:// (not secure) and WITHPRIORKNOWLEDGE.
Please update the URL accordingly.
https://gist.github.com/kunalekawde/1c6494b0aa4bf818ab0c42bb42497f5d
Please let me know if this works for you or if something is example is
incorrect.

> --
>
>   / daniel.haxx.se | Get the best commercial curl support there is - from me
>                    | Private help, bug fixes, support, ports, new features
>                    | https://www.wolfssl.com/contact/



-- 
~Kunal
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Reply via email to