On 01/26/2012 10:54 PM, Daniel Stenberg wrote:
> On Wed, 25 Jan 2012, Lijo Antony wrote:
>
>>> Maybe my design is a bit strange, but as I mentioned in an earlier
>>> post I can't think of a better design when using boost::asio on
>>> windows (using IOCP) with the curl multi-interface.
>>
>> I believe this is not specific to windows. I have observed the same in
>> a similar setup on linux. I am ignoring these dummy sockets as
>> mentioned by Christian earlier.
>
> But the code doesn't use any dummy sockets for the non-windows version
> so you're clearly not experiencing the same thing... and we've removed
> the dummy sockets from the windows version now!
>

Sorry for the delay in reply.

I was able to reproduce this behavior with the example program
evhiperfifo.c. I have modified evhiperfifo.c to support external sockets
by adding some code from externalsocket.c. I have attached the same. I
am using libcurl 7.24 on a linux machine. With this modified program, I
get the following output,

$ ./a.out
Creating named pipe "hiper.fifo"
Now, pipe some URL's into > hiper.fifo
connected to 127.0.0.1:80 with socket 6
Adding easy 0x154d570 to multi 0x1521610 (www.google.com)
multi_timer_cb 1
timer_cb w 0x7fffc4e42998 revents 256
Progress: www.google.com (0/0)
sock_cb e 0x154d570 s 7 what 1 cbp 0x7fffc4e42960 sockp (nil)
socket callback: s=7 e=0x154d570 what=IN Adding data: IN
setsock
Progress: www.google.com (0/0)
multi_timer_cb 5000
REMAINING: 1
event_cb w 0x1569610 revents 1
sock_cb e 0x154d570 s 7 what 4 cbp 0x7fffc4e42960 sockp 0x15695f0
socket callback: s=7 e=0x154d570 what=REMOVE
remsock
* About to connect() to www.google.com port 80 (#0)
opensocket called, returning socket 6
* Trying 173.194.73.104...
* connected
* Connected to www.google.com (173.194.73.104) port 80 (#0)
Progress: www.google.com (0/0)
> GET / HTTP/1.1
Host: www.google.com
Accept: */*

Progress: www.google.com (0/0)
sock_cb e 0x154d570 s 6 what 1 cbp 0x7fffc4e42960 sockp (nil)
socket callback: s=6 e=0x154d570 what=IN Adding data: IN
setsock
multi_timer_cb 3000
REMAINING: 1
event_cb w 0x1569610 revents 1
< HTTP/1.1 200 OK
< Date: Sun, 25 Mar 2012 13:03:11 GMT
< Server: Apache/2.2.20 (Ubuntu)
< Last-Modified: Wed, 03 Aug 2011 12:45:10 GMT
< ETag: "4447e-b1-4a9993c198282"
< Accept-Ranges: bytes
< Content-Length: 177
< Vary: Accept-Encoding
< Content-Type: text/html
< X-Pad: avoid browser bug
<
Progress: www.google.com (177/177)
* Connection #0 to host www.google.com left intact
sock_cb e 0x154d570 s 6 what 4 cbp 0x7fffc4e42960 sockp 0x15695f0
socket callback: s=6 e=0x154d570 what=REMOVE
remsock
multi_timer_cb 3000
REMAINING: 0
DONE: http://www.google.com => (0)
multi_timer_cb -1
timer_cb w 0x7fffc4e42998 revents 0
REMAINING: 0
last transfer done, kill timeout

Here we can see that curl uses socket 6 for transfer, which is the
external socket returned by the opensocket callback. But curl also
creates another socket, socket 7 internally, and it is being used during
the name lookup. I am not sure this is a dummy socket mentioned earlier
but I believe this is the same behavior observed by Christian on windows
as well.

My issue with this extra socket is, since I don't open this socket, I
cannot manage this socket using boost::asio library on windows.
As a result even though name lookup completes immediately, I cannot call
multi_perform till the previous timeout is hit. This effectively delays
the transfer by 2-5 seconds.

-lijo

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