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

attached mail follows:

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 <dan_at_coneharvesters.com>
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
>
Received on 2009-04-09