Hi,
I have a query with regards to the curl error.
I am facing the issue of the curl_easy_perform error "couldn't connect to
host" on making rapid web requests.
I am using libcurl on VxWorks platform. This same issue was raised earlier
with windows platform (please find the mail attached).
On getting the libcurl error I did inetstatShow and observerd that the tcp
sockets get into the TIME_WAIT (as can be seen below). But I have verified
that the webserver is running fine and is sending and receiving the
messages.
inetstatShow
Active Internet connections (including servers)
PCB Proto Recv-Q Send-Q Local Address Foreign Address
(state)
-------- ----- ------ ------ --------------------- ---------------------
-------
81ce8380 TCP 0 0 198.152.137.210.1268 198.152.137.209.80
TIME_WAIT
81ce80e4 TCP 0 0 198.152.137.210.1267 198.152.137.209.80
TIME_WAIT
81ce908c TCP 0 0 198.152.137.210.1266 198.152.137.209.80
TIME_WAIT
81ce8df0 TCP 0 0 198.152.137.210.1265 198.152.137.209.80
TIME_WAIT
81ce8b54 TCP 0 0 198.152.137.210.1264 198.152.137.209.80
TIME_WAIT
81ce861c TCP 0 0 198.152.137.210.1263 198.152.137.209.80
TIME_WAIT
81ce73d8 TCP 0 0 198.152.137.210.1262 198.152.137.209.80
TIME_WAIT
81ce7e48 TCP 0 0 198.152.137.210.1261 198.152.137.209.80
TIME_WAIT
81ce88b8 TCP 0 0 198.152.137.210.1260 198.152.137.209.80
TIME_WAIT
81ce713c TCP 0 0 198.152.137.210.1259 198.152.137.209.80
TIME_WAIT
81ce6ea0 TCP 0 0 198.152.137.210.1258 198.152.137.209.80
TIME_WAIT
81ce6968 TCP 0 0 198.152.137.210.1257 198.152.137.209.80
TIME_WAIT
81ce6c04 TCP 0 0 198.152.137.210.1256 198.152.137.209.80
TIME_WAIT
81ce66cc TCP 0 0 198.152.137.210.1255 198.152.137.209.80
TIME_WAIT
81ce6430 TCP 0 0 198.152.137.210.1254 198.152.137.209.80
TIME_WAIT
81ce9328 TCP 0 0 198.152.137.210.1253 198.152.137.209.80
TIME_WAIT
81ce95c4 TCP 0 0 198.152.137.210.1252 198.152.137.209.80
TIME_WAIT
81ce9860 TCP 0 0 198.152.137.210.1251 198.152.137.209.80
TIME_WAIT
81ce9afc TCP 0 0 198.152.137.210.1250 198.152.137.209.80
TIME_WAIT
81ce9d98 TCP 0 0 198.152.137.210.1249 198.152.137.209.80
TIME_WAIT
81cea034 TCP 0 0 198.152.137.210.1248 198.152.137.209.80
TIME_WAIT
81cea2d0 TCP 0 0 198.152.137.210.1247 198.152.137.209.80
TIME_WAIT
81cea56c TCP 0 0 198.152.137.210.1246 198.152.137.209.80
TIME_WAIT
81cea808 TCP 0 0 198.152.137.210.1245 198.152.137.209.80
TIME_WAIT
81ceaaa4 TCP 0 0 198.152.137.210.1244 198.152.137.209.80
TIME_WAIT
81cead40 TCP 0 0 198.152.137.210.1243 198.152.137.209.80
TIME_WAIT
81ceafdc TCP 0 0 198.152.137.210.1242 198.152.137.209.80
TIME_WAIT
81ceb278 TCP 0 0 198.152.137.210.1241 198.152.137.209.80
TIME_WAIT
81ceb514 TCP 0 0 198.152.137.210.1240 198.152.137.209.80
TIME_WAIT
81ceb7b0 TCP 0 0 198.152.137.210.1239 198.152.137.209.80
TIME_WAIT
81ceba4c TCP 0 0 198.152.137.210.1238 198.152.137.209.80
TIME_WAIT
81cebce8 TCP 0 0 198.152.137.210.1237 198.152.137.209.80
TIME_WAIT
81cebf84 TCP 0 0 198.152.137.210.1236 198.152.137.209.80
TIME_WAIT
81cec220 TCP 0 0 198.152.137.210.1235 198.152.137.209.80
TIME_WAIT
81cec4bc TCP 0 0 198.152.137.210.1234 198.152.137.209.80
TIME_WAIT
81cec758 TCP 0 0 198.152.137.210.1233 198.152.137.209.80
TIME_WAIT
81cec9f4 TCP 0 0 198.152.137.210.1232 198.152.137.209.80
TIME_WAIT
81cecc90 TCP 0 0 198.152.137.210.1231 198.152.137.209.80
TIME_WAIT
81cecf2c TCP 0 0 198.152.137.210.1230 198.152.137.209.80
TIME_WAIT
81ced1c8 TCP 0 0 198.152.137.210.1229 198.152.137.209.80
TIME_WAIT
81ced464 TCP 0 0 198.152.137.210.1228 198.152.137.209.80
TIME_WAIT
81ced700 TCP 0 0 198.152.137.210.1227 198.152.137.209.80
TIME_WAIT
81ced99c TCP 0 0 198.152.137.210.1226 198.152.137.209.80
TIME_WAIT
81cedc38 TCP 0 0 198.152.137.210.1225 198.152.137.209.80
TIME_WAIT
81ceded4 TCP 0 0 198.152.137.210.1224 198.152.137.209.80
TIME_WAIT
81cee170 TCP 0 0 198.152.137.210.1223 198.152.137.209.80
TIME_WAIT
81ce7bac TCP 0 0 198.152.137.210.5060 192.168.237.48.49105
ESTABLISHED
81ce7910 TCP 0 0 198.152.137.210.1181 192.168.237.48.5060
ESTABLISHED
81ce7674 TCP 0 0 0.0.0.0.5060 0.0.0.0.0
LISTEN
81cf5e04 UDP 0 0 0.0.0.0.5005 0.0.0.0.0
81cf5d54 UDP 0 0 0.0.0.0.5004 0.0.0.0.0
81cf5ca4 UDP 0 0 0.0.0.0.68 0.0.0.0.0
value = 1 = 0x1
->
The connection can be resumed only after around 10-15 seconds and the
application runs fine after that.
Please let me know if we have any solution to this problem.
Thanks and Regards,
Pallavi Agrawal,
Project Engineer
PDC-1 ,Wipro Technologies
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
--- Begin Message ---
I did a netstat -abn, and noticed that upto 127.0.0.1:5000 were used,
and 5000 is the default maximum for ephemeral ports in windows.
And given that the timewait before these ports are released is 4
minutes. I think that's what is causing my problems.
Do you have any recommendations on sniffers that have loopback support
for windows?
Thanks.
On Sun, Apr 20, 2008 at 7:14 PM, Dan Fandrich <[email protected]>
wrote:
>
> On Sat, Apr 19, 2008 at 11:49:08PM -0700, Vijay Mani wrote:
> > I'm using the libcurl 7.18 (no ssl) for windows. We essentially
> > have a java server (running embedded jetty webserver) running on the
> > localhost. For each webrequest that we make we create a new handle
> > using curl_easy_init() and clean it up with curl_easy_cleanup. This
> > works , except sometimes when we're making requests in rapid
> > succession (sometimes in a matter of milli-seconds) we get a
> > "couldn't connect to host" error, and this lasts for requests made for
> > about 10 seconds.
> > We've verified that the webserver is indeed alive and running, and not
> > rejecting connections.
> >
> > Any ideas?
>
> It could be that you're running out of sockets on the client side--TCP
> sockets need to be kept around for a bit after closure. Does a packet
> sniffer shed any light on the possible cause?
>
> >>> Dan
> --
> http://www.MoveAnnouncer.com The web change of address
service
> Let webmasters know that your web site has moved
>
--- End Message ---
