[Solved] QNetworkAccessManager/QNetworkReply timeout value (?)



  • Hello there,

    This week my Internet connection was failing and thanks to that issue I could discover
    a bug in my application:

    1. When it starts, a QNetworkRequest is sent through the network only to download and
      to parse an html file (a very simple task really).
    2. If my Internet access is ok and I want to close my application, it exists immediately with
      no problem.
    3. If my Internet access is not ok (DNS issues, etc) then, an annoying delay happens before
      the application is closed.

    After a while looking for the cause of the delay, I found out this:

    The signals emitted by the QNetworkAccessManager/QNetworkReply classes when there's a
    network error are triggered too many seconds later, causing the delay.

    I tried to delete these classes from my destructor method to accelerate the application exit,
    but it was useless. So, what should I do? What is the best way I can deal with this issue when
    my Internet connection is failing? Is there a way to accelerate the application exit in a case
    like this?

    Thanks for your help!



  • Did you try to call "abort() ":http://doc.qt.nokia.com/4.7/qnetworkreply.html#abort on the QNetworkReply returned from QNAM?



  • This is a little piece of the code I'm calling at the beginning of the program:

    @
    QNetworkAccessManager *manager;
    QNetworkReply *reply;

    k->manager = new QNetworkAccessManager(this);
    connect(k->manager, SIGNAL(finished(QNetworkReply*)),
            this, SLOT(closeRequest(QNetworkReply*)));
    
    k->request.setUrl(QUrl(url));
    k->request.setRawHeader("User-Agent", BROWSER_FINGERPRINT.toAscii());
    
    k->reply = k->manager->get(k->request);
    connect(k->reply, SIGNAL(error(QNetworkReply::NetworkError)),
           this, SLOT(slotError(QNetworkReply::NetworkError)));
    

    @

    I turned off my modem, then I started my stopwatch at the same time with the software and it takes 40 seconds to emit the signal: error(QNetworkReply::NetworkError)). In other words, the software needs 40 seconds to find out that there's no Internet access.

    I tried to use the method abort() as you suggested, but it seems that when I can call it is too late.

    Right now, my question is this: using Qt, what is the best way I can detect if my Internet access is ok? Can I do it in less than 40 seconds?

    Thanks :)



  • "The software" consists of Qt, some resolver libs, the operating system... From my experience, that long timespans until an error message are usually caused by DNS requests. It's Qt asking the system resolver for the IP address for a given name. The OS resolver sends out the request and waits a certain amount of time until the answer comes back. If not, it tries another nameserver (if configured) and so on, giving up eventually. There's hardly anything you can do to change this.

    As a workaround, you could use a startup timer. Start it with the maximum timeout you want to wait and connect it to a slot to abort the startup. In case the get is fine, just stop the timer and/or set a flag that everything went well.



  • Thanks for your comments, that's something I hadn't been thinking about. I'm going to make some test doing IP requests directly to see what is the best time I can achieve :)



  • Hi xtingray,
    I met the same issues with you. Could you share how did you resolved?

    Appriciate!


  • Hello there!

    The reason this thread appears as "solved" is due to the last answer of Volker. I mean, there's no official solution about this problem because it depends on many variables, several of them NO-Qt related :S

    I never tried the "startup timer" approach, but it seems to be a possible "work-around". Good luck!



  • i'm having the same issue but didn't find a solution yet, instead i found more questions but i created a minimal QCoreApplication example and engineered a network setup which is reproducible on your system, so in a nutshell: you can now reproduce this bug, see:
    "qt-QNetworkAccessManager":https://github.com/qknight/qt-QNetworkAccessManager-issues/tree/4e71a61f6ea21b7ffa7358763a79e4e97ed28b85

    there is one difference though:

    i had this issue also with QNetworkAccessManager but after playing with the issue for a while (/etc/resolv.conf) i now think it is DNS related so i was looking into QHostInfo::lookupHost

    this issue isn't closed yet and should be reopened. i will look into it again tomorrow. if someone has an idea what to do next, please give me a hint. i will probably look into the QHostInfo linux implementation.

    but the README.MD contains a detailed description of the setup and tests i was using.

    i'm using:

    • qt-4.8.4
    • nixos linux (nixos.org)
    • kernel 3.4.56

    best wishes,
    joachim schiele



  • i've made some traces and an minimal example to illustrate the problem, my repo on github.com linked below.

    discussion
    "qt-QNetworkAccessManager-issues discussion":https://github.com/qknight/qt-QNetworkAccessManager-issues/tree/a43f6f03e6b7899c6cff28c2f9df729a7f885593#discussion

    possible solution(s)
    "qt-QNetworkAccessManager-issues solution(s)":https://github.com/qknight/qt-QNetworkAccessManager-issues/tree/a43f6f03e6b7899c6cff28c2f9df729a7f885593#possible-solutions

    summary: in a nutshell
    Qt's getaddrinfo(..) abstraction must be changed to make the lookupHost(..) call really async. right now it is sync, when the network connection between client and DNS server is interrupted, which isn't that seldom as one might expect.

    should i fill a bug report? this problem isn't solved at all! ;-)

    best wishes,
    joachim schiele


  • Lifetime Qt Champion

    Hi and welcome to devnet,

    Since you've made quiet a lot of work about this, you really should create a bug report ! Posting the bug report link here would be also greatly appreciated.



  • i've added a new bug here, hope this is the right tracker!
    https://bugreports.qt-project.org/browse/QTBUG-33391

    thanks


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.