文章1：libcurl中发错重传机制

转载请注明出处 http://blog.csdn.net/yankai0219/article/details/8159351

0.序 1.libcurl与发错重传相关的内容    1）命令行    2）程序中没有专门进行发错重传的参数或函数 2.libcurl如何实现发错重传 3.总结

0.序

     本文目的：实现libcurl的发错重传机制

1.libcurl与发错重传相关的内容

      1）命令行选项 --retry<num>、 --retry-delay<seconds>和--retry-max-time<seconds>

               当传输过程中出现错误，如超时、FTP 5xxx返回码或者HTTP 5xx返回码，curl会按照设置进行重传，这几个选项都与重传有关。

               --retry <num>设置重试次数，--retry-delay <seconds>设置两次重试的间隔时间，--retry-max-time <seconds>设置两次重试间隔的最长时间。

               默认情况下，curl不进行重试；如果重试，第一次间隔1秒，之后每次都间隔上一次的2倍时 间，直到间隔时间达到10分钟，之后的重试都将采用10分钟间隔。如果这3个选项的值被重新设置，则执行设置值。

      2）程序中没有专门进行发错重传的参数或者函数。

               为什么如此说呢？通过libcurl的代码，我们可以清晰的发现这点。

               首先，明确一点：config->req_retry是代指剩余的重试次数。

               <1>在tool_getparam.c中的getparameter函数中，

               <2>在tool_operate.c中

                    

                <3>在tool_operate.c中，retry_numretries作为剩余的重试次数

          

               综上<1-3>所述，如果想要使用重传，就要给req_retry赋值。那么如何给req_retry赋值呢？稍后再论。因为config->req_retry首次出现是在getparameter函数中，那么我们来看看这个函数是做什么用的。

                 经过查证，getparameter函数作用：解析命令行参数，getparameter所做的事情就是根据命令行参数的设置，修改config数据结构，以此影响和调整curl的功能。

                  至此，我们发现，libcurl中出现的有关重传的内容，实际上就是为了执行命令行中--retry --retry-delay和retry-max-time的。

                    因此我们可以得出结论，程序中没有专门进行发错重传的参数或者函数。

2.libcurl如何实现发错重传呢？

          难道libcurl不能进行发错重传？？？？

          这个观点我自己都很难相信！

          我突然记起之前一篇文章中谈到curl_easy_perform的返回值。于是乎有所发现，curl_easy_perform正确时返回CURLE_OK，错误时会返回不同状态值。那么我们就可以利用其返回的不同状态值进行发错重传。

          如果只想对超时、FTP 5xxx返回码或者HTTP 5xx返回码这几种情况，进行发错重传，那么就可以在出现这几种状态值时，才重新进行curl_easy_perform的执行。我所采用的方法很简单，就是只要出错，我就进行重传。

           思路如下：当curl_easy_perform不能成功执行就执行for循环，不断执行curl_easy_perform，直到成功。如果成功，则退出for循环，继续执行。注：其实不能无限循环，因为一旦无限循环极有可能造成程序崩溃，因为有时候的确是不能发送成功。

          我的部分代码如下所示：只是在curl_easy_perform处增加for循环，其他代码未曾修改。

     

3.总结：

     尽管多数时候，只是使用libcurl的函数来实现相关功能，但大家不能忘记libcurl也是开源代码，因此当实在找不到解决方法时，不妨简单的从源码进行分析，说不定就能找到不错的思路

          

文章参考：

http://hi.baidu.com/wkhaxwbkznbnpsq/item/5a6dba8d6b20182c100ef384

  http://blog.csdn.net/kevin_zqw/article/details/6927227