> If we specify CURLMOPT_MAX_HOST_CONNECTIONS > 1 and try to initiate
multiple
> HTTP/2 transfers, libcurl tries to open new connection instead of reusing.

>>Yes and no.

>>libcurl will focus on getting things done *now* rather than later so if
you
>>ask for >1 request at once, it will open separate connections for them.
Unless
>>you set CURLOPT_PIPEWAIT that tells curl it is fine to wait and see if it
can
>>rather multiplex instead of creating a new connection.

>>> CURLOPT_PIPEWAIT was set for the HTTP/2 transfer.

> As we need the option to be set of HTTP/1.1 also.

>>If you *need* to limit the number of connections then why does the HTTP
>>version matter?

>>> Then in case of HTTP/1.1 transfer, we want to have
CURLMOPT_MAX_TOTAL_CONNECTIONS = 1000, CURLMOPT_MAX_HOST_CONNECTIONS =
100.
If we run the HTTP/2 transfer with these set, libcurl opens a new
connection instead of multiplexing the next stream over earlier connection
and if the same HTTP/2
transfer is done with CURLMOPT_MAX_HOST_CONNECTIONS =1, it multiplexes the
next stream over existing connection.

There is another observation:
Even with normal dependency (not as in case#1) wherein for 3
requests(stream 1, 3, 5) -- 3(weight 20) depends on 1, 5(weight=80) depends
on 1, the server is not
showing consistent behavior of processing the requests.

I could see the following from the client side pcap:
10639 312.105487 192.168.148.121 127.0.0.1 HTTP2 110
HEADERS[39]: POST /worker/TestMsg?22
Stream: HEADERS, Stream ID: 39, Length 33, POST /worker/TestMsg?22
    Length: 33
    Type: HEADERS (1)
    Flags: 0x24
        .... ...0 = End Stream: False
        .... .1.. = End Headers: True
        .... 0... = Padded: False
        ..1. .... = Priority: True
        00.0 ..0. = Unused: 0x00
    0... .... .... .... .... .... .... .... = Reserved: 0x0
    .000 0000 0000 0000 0000 0000 0010 0111 = Stream Identifier: 39
    [Pad Length: 0]
    0... .... .... .... .... .... .... .... = Exclusive: False
    .000 0000 0000 0000 0000 0000 0010 0101 = Stream Dependency: 37
    Weight: 19
    [Weight real: 20]
    Header Block Fragment:
83049063c1ecea5b21aeb6379509d089bfc10b86c0bfbe0f...
    [Header Length: 181]
    [Header Count: 7]
    Header: :method: POST
    Header: :path: /worker/TestMsg?22
    Header: :scheme: http
    Header: :authority: goodbye-world
    Header: accept: */*
    Header: content-type: application/json
    Header: content-length: 103

10660 312.111272 192.168.148.121 127.0.0.1 HTTP2 82
PRIORITY[39]
Stream: PRIORITY, Stream ID: 39, Length 5
    Length: 5
    Type: PRIORITY (2)
    Flags: 0x00
        0000 0000 = Unused: 0x00
    0... .... .... .... .... .... .... .... = Reserved: 0x0
    .000 0000 0000 0000 0000 0000 0010 0111 = Stream Identifier: 39
    0... .... .... .... .... .... .... .... = Exclusive: False
    .000 0000 0000 0000 0000 0000 0000 0000 = Stream Dependency: 0
    Weight: 19
    [Weight real: 20]

The HEADER frame seems to send the dependency properly, but later PRIORITY
is sent for same stream id but the dependency is 0.

Thanks

On Wed, Mar 20, 2019 at 12:42 AM Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Tue, 19 Mar 2019, Kunal Ekawde via curl-library wrote:
>
> > For #1 case, may be its not logical to specify dependency on the handle
> > currently being setup.
>
> Easy handles is really the only identifier to a transfer that we have in
> the
> API so using something *else* would be strange I think.
>
> I suspect very few users ever actually used HTTP/2 stream dependencies
> much
> with curl so your experiences are indeed valuable but if you run into
> issues,
> it might simply be because nobody else ran into those or at least nobody
> else
> reported them.
>
> > Another concern is that of multiplexing streams. So when we support
> > HTTP/1.1 and HTTP/2 using same libcurl stack and same multi handle, how
> can
> > we specify CURLMOPT_MAX_TOTAL_CONNECTIONS &
> CURLMOPT_MAX_HOST_CONNECTIONS ?
>
> I don't think that's curl's job to tell. Those settings are there for the
> application to restrict libcurl and they do, independently of what HTTP
> version that is used.
>
> > If we specify CURLMOPT_MAX_HOST_CONNECTIONS > 1 and try to initiate
> multiple
> > HTTP/2 transfers, libcurl tries to open new connection instead of
> reusing.
>
> Yes and no.
>
> libcurl will focus on getting things done *now* rather than later so if
> you
> ask for >1 request at once, it will open separate connections for them.
> Unless
> you set CURLOPT_PIPEWAIT that tells curl it is fine to wait and see if it
> can
> rather multiplex instead of creating a new connection.
>
> > As we need the option to be set of HTTP/1.1 also.
>
> If you *need* to limit the number of connections then why does the HTTP
> version matter?
>
> --
>
> / daniel.haxx.se
>

-- 
~Kunal

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-03-20