Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re:Re: [HELP] What's the underlying connection reusing policy, can it be RR
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: 白水月 via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 20 Jan 2022 15:19:27 +0800 (CST)
Thanks for your reply,.<br/><br/>Yes, I don't do repeated request. Maybe come a request, then next one come an hour later. But the requests are latency concered(should be less than 50ms) . <br/><br/>If every request comes, then make a new connection to the server, the total cost of the request would probably exceed 50ms due to tcp handshake.<br/><br/>So I hope to keep the underlying connection in libcurl cache to stay as long as possible, such that once a request comes, <br/>there's a 'ready' connection(no need to establish from srcatch) to handle it.
在 2022-01-19 18:03:04，"Daniel Stenberg" <daniel_at_haxx.se> 写道：
>On Wed, 19 Jan 2022, 白水月 via curl-library wrote:
>
>I don't quite understand what you want to accomplish.
>
>The connection pool libcurl maintains is there to enable repeated requests
>to the same hosts to reuse connections.
>
>If you don't do repeated requests, like if the requests are done with so long
>interval that the connections are closed by the server before they are used
>again, then maybe just let that happen?
>
>> 4. As time pass by, some underlying TCP connection was close by the server.
>> The periodic keepalive request fail to save the underlying TCP connection
>> due to libcurl will reuse existing connection, which leads to one
>> connection(in this case) never send keepalive request to server.
>
>For most use cases it is most efficient to pick the most recently used
>connection for reuse (and not round-robin) - quite simply for better success
>rate. The longer a connection has been left idle, the bigger the risk that it
>doesn't work anymore.
>
>> Another "easy" approach is if we can set the resuse policy of existing
>> connections to Round Robin, it seems everything goes well. But I fail to
>> find out any stuff about the reusing policy. Is it possible to do this? And
>> what's best practise for the scenario that I faced?
>
>There's no such option available and I can't think of any proper way for an
>application to trick libcurl into behaving like this.
>
>If the connections are created at different times, there is
>CURLOPT_MAXLIFETIME_CONN that can make libcurl stop considering a connection
>for reuse once it has reached a certain age, but that doesn't seem to be very
>helpful for your case.
>
>--
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
Date: Thu, 20 Jan 2022 15:19:27 +0800 (CST)
Thanks for your reply,.<br/><br/>Yes, I don't do repeated request. Maybe come a request, then next one come an hour later. But the requests are latency concered(should be less than 50ms) . <br/><br/>If every request comes, then make a new connection to the server, the total cost of the request would probably exceed 50ms due to tcp handshake.<br/><br/>So I hope to keep the underlying connection in libcurl cache to stay as long as possible, such that once a request comes, <br/>there's a 'ready' connection(no need to establish from srcatch) to handle it.
在 2022-01-19 18:03:04，"Daniel Stenberg" <daniel_at_haxx.se> 写道：
>On Wed, 19 Jan 2022, 白水月 via curl-library wrote:
>
>I don't quite understand what you want to accomplish.
>
>The connection pool libcurl maintains is there to enable repeated requests
>to the same hosts to reuse connections.
>
>If you don't do repeated requests, like if the requests are done with so long
>interval that the connections are closed by the server before they are used
>again, then maybe just let that happen?
>
>> 4. As time pass by, some underlying TCP connection was close by the server.
>> The periodic keepalive request fail to save the underlying TCP connection
>> due to libcurl will reuse existing connection, which leads to one
>> connection(in this case) never send keepalive request to server.
>
>For most use cases it is most efficient to pick the most recently used
>connection for reuse (and not round-robin) - quite simply for better success
>rate. The longer a connection has been left idle, the bigger the risk that it
>doesn't work anymore.
>
>> Another "easy" approach is if we can set the resuse policy of existing
>> connections to Round Robin, it seems everything goes well. But I fail to
>> find out any stuff about the reusing policy. Is it possible to do this? And
>> what's best practise for the scenario that I faced?
>
>There's no such option available and I can't think of any proper way for an
>application to trick libcurl into behaving like this.
>
>If the connections are created at different times, there is
>CURLOPT_MAXLIFETIME_CONN that can make libcurl stop considering a connection
>for reuse once it has reached a certain age, but that doesn't seem to be very
>helpful for your case.
>
>--
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-01-20