Calling experienced network programmers

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
User avatar
pythoncoder
Posts: 4380
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Calling experienced network programmers

Post by pythoncoder » Thu Oct 20, 2016 4:12 pm

jms wrote:...But I believe the _only_ things we have here are socket timeouts and blocking through the usocket module. Good enough for everything you'll realistically do with the ESP8266.
Blocking drivers and ones which require long timeouts can be a major issue on devices which need to service hardware. Interrupts can fix some of these issues but some way of addressing concurrency is required (and does appear to be a work in progress).
Peter Hinch

Lysenko
Posts: 62
Joined: Wed Aug 17, 2016 1:21 pm

Re: Calling experienced network programmers

Post by Lysenko » Thu Oct 20, 2016 5:29 pm

jms wrote: But I believe the _only_ things we have here are socket timeouts and blocking through the usocket module. Good enough for everything you'll realistically do with the ESP8266.
It is rather the reverse in my opinion. Blocking sockets and/or lenfthy timeouts are perfectly adequate if you're running Linux/FreeRTOS on something like an i.MX28 since you can wrap everything network related in a thread pool in a different process from the HW I/O. If the network dies you pre-empt and kill the process from the supervisor, buffer the data stream and re-establish connectivity (or switch to an auxiliary server) with no real impact on HW interrupt handling, DMX streaming, screen updates or anything else (soft real) time critical. That's all a lot trickier with lower end stuff.

User avatar
kfricke
Posts: 342
Joined: Mon May 05, 2014 9:13 am
Location: Germany

Re: Calling experienced network programmers

Post by kfricke » Thu Oct 20, 2016 7:31 pm

The last two posts are hitting the mail on the head imho. And do also argue in the direction of being prepared to boot more often, when blocking sockets fail or the like. This also adds more value to not unnecessary wear flash when reconnect to a WiFi.

jms
Posts: 108
Joined: Thu May 05, 2016 8:29 pm
Contact:

Re: Calling experienced network programmers

Post by jms » Tue Oct 25, 2016 12:01 pm

I must apologise. I meant there _is_ control of timeout and blocking (or not) through usocket.

Whether they work properly and are configurable through things built on top (MQTT...) is another matter.

slzatz
Posts: 92
Joined: Mon Feb 09, 2015 1:09 am

Re: Calling experienced network programmers

Post by slzatz » Tue Oct 25, 2016 12:22 pm

With regard to MQTT -- in my less than mission critical application, the following has worked fine in a timer callback:

Code: Select all

try:
    # check for new mqtt message
    b = umc.check_msg()
except OSError as e:
    print("check_msg:", e)
    machine.reset()
On some WiFi networks, I can go hours without seeing a reset and on others, I can see several in an hour. For my app, being out of commission for the time it takes for a reset isn't a problem and main.py just calls the script in question following the reboot. I assume this won't work for more timing sensitive applications but as I said works fine for at least my situation.

User avatar
pythoncoder
Posts: 4380
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Calling experienced network programmers

Post by pythoncoder » Tue Oct 25, 2016 1:55 pm

A couple of points. @Damien has cautioned that using sockets in a timer callback is unreliable. Secondly I've encountered very rare occasions when a socket read or write seems to block forever.
Peter Hinch

jms
Posts: 108
Joined: Thu May 05, 2016 8:29 pm
Contact:

Re: Calling experienced network programmers

Post by jms » Wed Oct 26, 2016 2:14 pm

pythoncoder wrote:A couple of points. @Damien has cautioned that using sockets in a timer callback is unreliable. Secondly I've encountered very rare occasions when a socket read or write seems to block forever.
Block forever even when configured not to ?

Blocking forever on a normal blocking socket is quite possible though if kit obeyed the rules ICMP and TCP resets would often but not always clear them.

Lysenko
Posts: 62
Joined: Wed Aug 17, 2016 1:21 pm

Re: Calling experienced network programmers

Post by Lysenko » Wed Oct 26, 2016 3:02 pm

jms wrote: Block forever even when configured not to ?
To configure a socket not to block forever (which is the default) you need setsockopt to implement SO_RCVTIMEO and SO_SNDTIMEO.

User avatar
pythoncoder
Posts: 4380
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Calling experienced network programmers

Post by pythoncoder » Wed Oct 26, 2016 3:48 pm

My view is that the socket is behaving correctly but the MQTT library should implement timeouts.
Peter Hinch

Lysenko
Posts: 62
Joined: Wed Aug 17, 2016 1:21 pm

Re: Calling experienced network programmers

Post by Lysenko » Wed Oct 26, 2016 6:45 pm

pythoncoder wrote:My view is that the socket is behaving correctly but the MQTT library should implement timeouts.
If a layer 4 proticol like TCP locks up then there is nothing a layer 7 protocol like MQTT can do about it. That pre-supposes that the block is actually at transport level of course.

This is an ESP8266, right? Where is the poll_sockets callback implemented for that port? Looking at the code, the issue is either there or the hardware timer went into reverse or the issue is higher up.

Post Reply