c++ - libCurl 上传数据不活动超时不起作用

Question

我有一个在 powerpc 上运行的跨平台嵌入式 libCurl 客户端应用程序，它的行为与 Windows 对应程序不同。基本问题是我的客户端上传文件的远程服务器在返回 226 响应(表示上传成功)之前执行了很长的操作。此时远程 FTP 服务器实际上正在执行闪存回收，此操作最多可能需要 900 秒。实际上，我正在尝试在等待远程 226 或错误响应时使用数据不活动超时。

在 Windows 上这工作正常，但是在 PowerPC 嵌入式客户端上(我们链接到使用 Mentor Graphics Code Sourcery 工具链为 PowerGNU 编译的最新 libCurl-7.39.0 库)客户端在 FTP 不活动正好 60 秒后超时。

我设置计时器的方式如下面的代码片段所示(请注意，我确保 CURLOPT_FTP_RESPONSE_TIMEOUT 的值比 CURLOPT_TIMEOUT 低 1 秒。此外，值得注意的是 CURLOPT_CONNECTTIMEOUT 设置为 60秒(也许这是巧合，但在 powerPC linux 客户端上，不活动超时需要 CURLOPT_CONNECTTIMEOUT(即 60)秒)。我想知道是否有一些错误潜伏在 CURLOPT_CONNECTTIMEOUT 中是否覆盖或破坏了 linux 客户端上的 CURLOPT_FTP_RESPONSE_TIMEOUT？

除此之外，我的 curl 选项似乎工作正常。我读了 article关于 libCurl 中定时器的实现，似乎定时器是以某种“先过期”顺序组织的，也许在我更新默认 CURLOPT_FTP_RESPONSE_TIMEOUT(默认为无限期)时，它的插入会导致损坏定时器队列。

// if updating the module could potentially
// cause flash reclamation, set the command to response FTP
// timer to include both delivery time + the max expected
// time for the file put for the biggest file over BASE2 or BASET
auto flashReclTimeout = rContext.getFlashReclTimeout();
if (flashReclTimeout) {
    auto timeoutSecs = duration_cast<seconds>(flashReclTimeout.get());
    auto res = curl_easy_setopt(rContext.getCurlHandle(),
        CURLOPT_TIMEOUT, timeoutSecs.count()+1);
    res = curl_easy_setopt(rContext.getCurlHandle(),
        CURLOPT_FTP_RESPONSE_TIMEOUT, timeoutSecs.count());
    ss  << ", [flash reclamation timeout "
        << timeoutSecs.count()
        << "(s)]";
}
LOG_EVT_INFO(gEvtLog) << rLogPrefix << ss.str() << std::endl;

我的默认 libCurl 选项设置如下

/**
 * Sets the curl options using the current mContextInfo.
 *
 * This never sets the URI curl field as this must be
 * done outside the context object.
 */
void
SLDBContext::setCurlOptions() {
    CURL* pCurl = mCurlHandle.get();
    // reset all curl context info
    curl_easy_reset(pCurl);
    // DEOS does not support EPSV or EPRT

    auto res = curl_easy_setopt(pCurl, CURLOPT_FTP_USE_EPSV, 0L);
    res = curl_easy_setopt(pCurl, CURLOPT_FTP_USE_EPRT, 0L);
    res = curl_easy_setopt(pCurl, CURLOPT_NOSIGNAL, 1L);
#if 0
    // send out TCP keep-alive probes - not required
    res = curl_easy_setopt(pCurl, CURLOPT_TCP_KEEPALIVE, 1L);
    // check to ensure that this is supported
    if (res == CURLE_OK) {
        // wait for at least 30 seconds before sending keep-alive probes
        // every 2 seconds
        res = curl_easy_setopt(pCurl, CURLOPT_TCP_KEEPIDLE, 30L);
        res = curl_easy_setopt(pCurl, CURLOPT_TCP_KEEPINTVL, 30L);
    }
#endif
    // do not perform CWD when traversing the pseudo directories
    res = curl_easy_setopt(pCurl, CURLOPT_FTP_FILEMETHOD, CURLFTPMETHOD_NOCWD);
    res = curl_easy_setopt(pCurl, CURLOPT_CONNECTTIMEOUT, getConnectTimeoutSecs());

    if (!isPASVMode()) {
        res = curl_easy_setopt(pCurl, CURLOPT_FTPPORT, "-");
    }
    // used to capture header traffic
    if (mHeaderCallback) {
        res = curl_easy_setopt(pCurl, CURLOPT_WRITEHEADER, mpHeaderStream);
        res = curl_easy_setopt(pCurl, CURLOPT_HEADERFUNCTION, mHeaderCallback);
    }
    // for FTP GET operations
    if (mWriteDataCallback) {
        res = curl_easy_setopt(pCurl, CURLOPT_WRITEDATA, &mScratchBuffer);
        res = curl_easy_setopt(pCurl, CURLOPT_WRITEFUNCTION, mWriteDataCallback);
    }
    // for FTP PUT operations
    if (mReadFileCallback) {
        res = curl_easy_setopt(pCurl, CURLOPT_READFUNCTION, mReadFileCallback);
    }

    // @JC this feature may be causing slowdowns on the target platform
#if 0
    // capture error details to this buffer
    res = curl_easy_setopt(pCurl, CURLOPT_ERRORBUFFER, mErrorBuffer.get());
#endif

    // progress callback used to track upload progress only
    if (mProgressCallback) {
        res = curl_easy_setopt(pCurl, CURLOPT_XFERINFOFUNCTION, mProgressCallback);
        res = curl_easy_setopt(pCurl, CURLOPT_NOPROGRESS, 0L);
        res = curl_easy_setopt(pCurl, CURLOPT_XFERINFODATA, nullptr);
    }

    // verbose logging
    if (mDebuggingCallback) {
        res = curl_easy_setopt(pCurl, CURLOPT_VERBOSE, 1L);
        res = curl_easy_setopt(pCurl, CURLOPT_DEBUGFUNCTION, mDebuggingCallback);
        res = curl_easy_setopt(pCurl, CURLOPT_DEBUGDATA, nullptr);
    } else {
        res = curl_easy_setopt(pCurl, CURLOPT_VERBOSE, 0L);
        res = curl_easy_setopt(pCurl, CURLOPT_DEBUGDATA, nullptr);
    }

    // disable Nagle algorithm - to fix slowdown in bulk transfers
    // with large data files @JC not necessary
    // res = curl_easy_setopt(pCurl, CURLOPT_TCP_NODELAY, 1L);
    if (mSocketOptionCallback) {
        res = curl_easy_setopt(pCurl, CURLOPT_SOCKOPTDATA, nullptr);
        res = curl_easy_setopt(pCurl, CURLOPT_SOCKOPTFUNCTION, mSocketOptionCallback);
    }
}

Answer 1

实际上我发现了问题 - 结果主要是我的问题:

在我们的目标平台上进行了大量调试和打印输出后，事实证明错误的来源是 75% 的应用程序问题(我的)和 25%(在我看来)由于 using 的弱点导致的 libCurl 问题松散耦合的 va_args 在设置 libCurl 选项时从可变长度参数列表中提取参数。该问题与隐含的“long long”到“long”转换以及 PowerPC 平台上的 Endian 相关问题有关，而这在 Windows 平台上不是问题。

我在 C++ 应用程序中使用 libCurl 来满足我们的 FTP 客户端需求 - 链接到标准模板 C++ 库。我使用 std::chrono::seconds 对象来设置时间和持续时间 libCurl 选项。然而，在幕后，std::chrono::seconds 是一个相当复杂的模板类型，内部表示为 n 个 8 字节 PPC 'long long'，它不同于在下面的选项中硬编码的 4 字节 PPC 'long' .由于传入的“long long”参数与实际的“long”之间存在松耦合，在 CURLOPT_SERVER_RESPONSE_TIMEOUT 中设置的值实际上是 power PC 平台上 8 字节的“long long”中不正确的 4 字节。我通过编写一段代码来验证它在 Windows 上的工作方式而不是在我们的 32 位 PPC 嵌入式目标上的工作方式来证实这一点。

我在应用程序级别设置固定代码的方法是确保有一个显式转换为与 va_arg 第二个参数相同的类型——这是必需的，因为 seconds::count() 方法返回一个 long long，没有这个 CURLOPT_SERVER_RESPONSE_TIMEOUT 选项令人惊讶地设置为 0。希望这对您有帮助

if (flashReclTimeout) {
    // fix for broken flash reclamation timer on target platform
    // caused by 'long long' to 'long' conversion always
    // setting a 0 in the associated timers.
    auto timeoutSecs = duration_cast<seconds>(flashReclTimeout.get());
    /*auto res = */curl_easy_setopt(rContext.getCurlHandle(),
        CURLOPT_TIMEOUT, static_cast<long>(timeoutSecs.count() + 1));
    /*auto res = */curl_easy_setopt(rContext.getCurlHandle(),
        CURLOPT_FTP_RESPONSE_TIMEOUT, static_cast<long>(timeoutSecs.count()));
    ss  << ", [flash reclamation timeout "
        << timeoutSecs.count()
        << "(s)]";
}

这是 libCurl 中的实现，其中设置了 CURLOPT_SERVER_RESPONSE_TIMEOUT(是我在我的应用程序中使用的 CURLOPT_FTP_RESPONSE_TIMEOUT 选项的同义词。

CURLcode Curl_setopt(struct SessionHandle *data, CURLoption option,
                     va_list param)
{
  char *argptr;
  CURLcode result = CURLE_OK;
  long arg;
#ifndef CURL_DISABLE_HTTP
  curl_off_t bigsize;
#endif

  switch(option) {
  case CURLOPT_DNS_CACHE_TIMEOUT:
 .  . .

  case CURLOPT_SERVER_RESPONSE_TIMEOUT:
    /*
     * Option that specifies how quickly an server response must be obtained
     * before it is considered failure. For pingpong protocols.
     */
    data->set.server_response_timeout = va_arg( param , long ) * 1000;
    break;

libCurl 用户论坛上的 Dan Fandrich 正确指出:

CURLOPT_FTP_RESPONSE_TIMEOUT (formerly CURLOPT_SERVER_RESPONSE_TIMEOUT) is documented to take a long. There's no ambiguity about that. Since curl_easy_setopt uses varargs, there's not much choice other than casting in this situation, or with any other argument to curl_easy_setopt that doesn't match the requested type. I'm glad you found the source of problems in your program, but as the man page for curl_easy_setopt says:

Read this manual carefully as bad input values may cause libcurl to behave badly!

大多数 LibCurl 的维护者/作者 Dan Steinberg 回应了我关于 varargs 是一个容易出现用户错误的弱 api 的断言:

Yeah, using varargs for this was probably not the wisest design choice when we created the API some 14 years ago but it also why we continously stress the exact variable type to pass in for each option.

The typecheck-gcc.h macromania is another way we try to help users to discover these mistakes.

总而言之，实际问题是我的 - 没有正确阅读文档，但是 varargs api 的潜在弱点导致了 API 的固有弱点 - 吸取的教训是阅读手册并非常非常小心任何在我的特定情况下，从 std::chrono::duration 类型自动转换底层类型。