Phpcurl millisecond timeout for a "Bug" _php tutorial

Our service recently upgraded PHP to use Libcurl, expecting the new version of Libcurl to support the millisecond timeout, allowing finer control over the backend interface timeouts, thus improving overall response time.

However, we found that, on our CentOS server, when you set a timeout of less than 1000ms, curl does not initiate any requests and returns a time-out error (timeout reached 28).

Originally, there is a hole in it, curl default, on the Linux system, if the use of system-standard DNS resolution, you will use Sigalarm to provide control of the domain name resolution timeout function, but Sigalarm does not support less than 1s timeout, so in Libcurl 7.28.1 in the code (note the Chinese comment line):

int curl_resolv_timeout (struct connectdata *conn,

• const char *hostname,
• int port,
• struct curl_dns_entry **entry,
• long Timeoutms)
• {
• ...
• ...
• #ifdef use_alarm_timeout
• if (data->set.no_signal)
• /* Ignore The timeout when signals is disabled */
• timeout = 0;
• Else
• timeout = Timeoutms;
• if (!timeout)
• /* use_alarm_timeout defined, but no timeout actually requested */
• RET Urn CURL_RESOLV (conn, hostname, port, entry);
• if (Timeout < 1000)//if less than 1000, direct timeout returned
• /The alarm () function only provides integer second Resolution, so if
• we want to wait less than one second we must bail out already now. */
• return Curlre Solv_timedout;
• ....
• ....

As you can see, when your timeout is less than 1000ms, name parsing will return directly to Curlresolv_timeout, which will eventually lead to Curle_operation_timedout, then error, timeout reached ...

This .... Too much, Daddy? Can we not use milliseconds to timeout? What do you offer this function for?

Still look at the code, or just that code, note this (Chinese comment line):

• #ifdef Use_alarm_timeout
• if (data->set.no_signal)//Note this line
• /* Ignore The timeout when signals is disabled */
• Timeout = 0;
• Else
• Timeout = Timeoutms;
• if (!timeout)
• /* Use_alarm_timeout defined, but no TIMEOUT actually requested */
• Return CURL_RESOLV (conn, hostname, port, entry);
• if (Timeout < 1000)
• /* the alarm () function only provides integer second resolution, so if
• We want to wait less than one second we must bail off already now. */
• return curlresolv_timedout;

It seems that as long as set.no_signal this thing is 1, it can be bypassed ... So what's this thing?

This is simple, grep the code, found:

• Case Curlopt_nosignal:
• /*
• * The application asks not to set any signal () or alarm () handlers,
• * Even when using a timeout.
• */
• Data->set.no_signal = (0! = va_arg (param, long))? True:false;
• Break

Haha, the original is this goods:

• curl_setopt ($ch, curlopt_nosignal, 1);
• ?>

Plus this opt, everything is finally normal!

Postscript:

In this way, there will be a hidden danger, that is, DNS resolution will not be limited by the timeout, which is within the company, generally no problem, but in case the DNS server hang, it may cause the application timeout.

So is there any other way?

Yes, that's Mike's warning, we can have Libcurl use C-ares (C library for asynchronous DNS requests) to do name resolution. The specific can be in the Config curl:

• ./configure--enable-ares[=path]

So you don't have to set nosignal.

PS, why the "Bug", I just curious, why don't they setitimer?

Reference: Http://stackoverflow.com/questions/7987584/curl-timeout-less-than-1000ms-always-fails
Author: laruence
This address: http://www.laruence.com/2014/01/21/2939.html

http://www.bkjia.com/PHPjc/735044.html www.bkjia.com true http://www.bkjia.com/PHPjc/735044.html techarticle our service recently upgraded PHP to use Libcurl, expecting the new version of Libcurl to support the millisecond timeout, allowing finer control over the backend interface timeouts, thus improving overall response ...

