cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: How to cleanly close the curl socket in case of multi interface?

From: nikhil ap <niks3089_at_gmail.com>
Date: Sun, 21 Sep 2014 10:26:50 +0530

"I can't say I fully understand what you want. You mean only one single
connection libcurl sets up should be re-used and no other? That's not a
setup easily constructed with libcurl I'd say."

This is taken from hiperfifo.c. I have added the stats part.

typedef struct _ConnInfo
{
  CURL *easy;
  char *url;
  GlobalInfo *global;
  char error[CURL_ERROR_SIZE];
  stats my_stats;
  Sockinfo *sock;
} ConnInfo;

ConnInfo according to me is a TCP connection object which defined by <soure
ip, dest ip, source port, dest port> and should have just a single socket
attached to it.

For each easy handle, in CURLINFO_PRIVATE option, conninfo is passed.

I have created 2 connection objects and would like to send 10 GET requests
using multi handle:

Initially,
Conn 1: easy 1 is used to make the transfer
Conn 0: easy 0 is used to make the transfer.

I update stats for conn 0 and conn 1 when i get info from CURLINFO_PRIVATE

Next iteration,
Conn 1: easy 1 is used to make the transfer

Conn 0: *easy 1* is used to make the transfer. /* This updates the stats
for Conn 1!! */

Above, since conn1 is passed as private info, stats for conn 1 gets updated
when the request is completed which is incorrect and I have added an assert
to catch this behavior.

Why I need to maintain connection level stats and bother about connection?
Simple answer, it's a requirement! :-)

How do I fix this problem? How will know for which *TCP* connection an easy
handle is used?

Detailed logs from my application can be found below.

2014-09-21 10:00:53.659590 INFO
16505:47926596110656:src/http/http_connection.c:124 Connections: 0,
Requests completed: 0
2014-09-21 10:00:53.661180 INFO
16505:47926596110656:src/http/http_connection.c:391 Sent GET request for
connection Conn: 1
2014-09-21 10:00:53.661257 INFO
16505:47926596110656:src/http/http_connection.c:391 Sent GET request for
connection Conn: 0
2014-09-21 10:00:53.663802 INFO
16505:47926596110656:src/http/http_connection.c:59 Checking authenticity
for conn: 1 local port: 0, received local port: 38688
2014-09-21 10:00:53.663840 WARN
16505:47926596110656:src/http/http_connection_fsm.c:164 Sending request for
conn: 1
2014-09-21 10:00:53.663858 INFO
16505:47926596110656:src/http/http_connection.c:124 Connections: 0,
Requests completed: 1
2014-09-21 10:00:53.664069 INFO
16505:47926596110656:src/http/http_connection.c:59 Checking authenticity
for conn: 0 local port: 0, received local port: 38689
2014-09-21 10:00:53.664096 WARN
16505:47926596110656:src/http/http_connection_fsm.c:164 Sending request for
conn: 0
2014-09-21 10:00:53.665152 INFO
16505:47926596110656:src/http/http_connection.c:391 Sent GET request for
connection Conn: 1
2014-09-21 10:00:53.665184 INFO
16505:47926596110656:src/http/http_connection.c:124 Connections: 0,
Requests completed: 2
2014-09-21 10:00:53.665234 INFO
16505:47926596110656:src/http/http_connection.c:391 Sent GET request for
connection Conn: 0
2014-09-21 10:00:53.665588 INFO
16505:47926596110656:src/http/http_connection.c:59 Checking authenticity
for conn: 1 local port: 38688, received local port: 38688
2014-09-21 10:00:53.665622 WARN
16505:47926596110656:src/http/http_connection_fsm.c:164 Sending request for
conn: 1
2014-09-21 10:00:53.665639 INFO
16505:47926596110656:src/http/http_connection.c:124 Connections: 0,
Requests completed: 3
2014-09-21 10:00:53.665707 INFO
16505:47926596110656:src/http/http_connection.c:59 Checking authenticity
for conn: 0 local port: 38689, received local port: 38689
2014-09-21 10:00:53.665731 WARN
16505:47926596110656:src/http/http_connection_fsm.c:164 Sending request for
conn: 0
2014-09-21 10:00:53.667143 INFO
16505:47926596110656:src/http/http_connection.c:391 Sent GET request for
connection Conn: 0
2014-09-21 10:00:53.667217 INFO
16505:47926596110656:src/http/http_connection.c:391 Sent GET request for
connection Conn: 1
2014-09-21 10:00:53.667246 INFO
16505:47926596110656:src/http/http_connection.c:124 Connections: 0,
Requests completed: 4
2014-09-21 10:00:53.667555 INFO
16505:47926596110656:src/http/http_connection.c:59 Checking authenticity
for conn: 0 local port: 38689, received local port: 38688. Failed!!

On Fri, Sep 19, 2014 at 7:25 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Fri, 19 Sep 2014, nikhil ap wrote:
>
> CURLOPT_FORBID_REUSE closes the connection immediately and is suited if I
>> have to make 1 request / connection. If I have to make 5 requests/
>> connection using the same handle, then I cannot use this option because for
>> the 2nd request is going to create a new connection which is not what I
>> want.
>>
>
> That's a might weird use case. Why forcibly close it after the 5th request?
>
> Anyway, set CURLOPT_FORBID_REUSE on the easy handle doing the 5th request
> (if you can figure out which that is) and it'll close the connection after
> its transfer.
>
> To overcome this, I thought I could set CURLOPT_MAXCONNECTS to 1 to force
>> the connection cache to be 1 but since I am using multi interface, I used
>> CURLMOPT_MAXCONNECTS and set its value to 1.
>>
>> This however closed the connection when there were more than one open
>> connection and according to the document, "When the cache is full, curl
>> closes the oldest one in the cache to prevent the number of open
>> connections from increasing" this is a right behavior. Is there a way to
>> avoid this behavior? Having easy handle re-using different TCP connection
>> messes with my stats.
>>
>
> Right, but you're trying very hard to work around libcurl's features and
> impose stupid connection restrictions. libcurl don't expose that level of
> control of which connections that are used by which easy handles - it
> actually abstracts that way since application mostly don't need to bother.
>
> I would like to use and re-use each easy handle for just one connection
>> in multi-interface enviornment. Is this possible?
>>
>
> I can't say I fully understand what you want. You mean only one single
> connection libcurl sets up should be re-used and no other? That's not a
> setup easily constructed with libcurl I'd say.
>
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>

-- 
niks

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-09-21