urequests timeouts

  • I'm running a battery powered GPY so looking to minimise the active time between deepsleeps. In regular python I'd use

    r=requests.get(VERSION_API_URL + site, timeout=5)

    to limit the time waiting for a server response to 5s. Unfortunately urequests doesn't accept a timeout

    Traceback (most recent call last):
      File "<stdin>", line 198, in _updater
      File "/flash/lib/urequests.py", line 112, in get
    TypeError: function does not take keyword arguments

    and the default timeout it uses is quite long (30s). Given that a normal wake from deepsleep-attach/connect 4G modem-read sensors-send data cycle takes just 20s, the long wait for a stalled connection is a real pain.

    Any suggestions from those-in-the-know for a workaround?

  • @jcaron Yeah I had to re do urequests. So hard for a plod to do surgery on a library file & so distracting from the main task of writing a bullet proof main.py. Who are these geniuses that write socket programs sans timeouts or try/exception protection?

  • @kjm One option could could be to use a separate timer to cut things short if things don't go as planned, but that would have part of the issues you mentioned earlier (could abort a valid request in progress, etc.), unless you modify urequests to use that timer just for the getaddrinfo (and possibly initial connect) part, then cancel the timer.

  • OK I have a better handle on the problem now. Maybe if I explain it better some wunderkind can offer a solution? The problem is urequests uses getaddrinfo which can't accept a timeout (https://stackoverflow.com/questions/26857922/pass-timeout-to-socket-getaddrinfo/28120166#28120166). So if the DNS lookup fails urequests hangs for a bit. Strangely the hang time is different if it runs from Atom (~10s) to if it runs from flash in the GPY (~30s).

    Having a battery powered GPY stalled waiting for a 30s timeout is hopeless so I'm looking for a fix. All suggestions gratefully received!

  • I worked out how to set a timeout in urequests but it's a blunt instrument. Firstly it always waits for the timeout regardless of how long it takes to get a server response. Secondly it will abort a download mid stream if the timeout expires. Surely there is something better than this?

    What I need is a timeout that limits how long to wait for a server response but cancels once the server starts responding. This would give me data as soon as it was available & would stop the timeout cutting off a response mid stream.

Log in to reply

Pycom on Twitter