Calling experienced network programmers

[pythoncoder]

...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).

[Lysenko]

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.

[kfricke]

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]

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]

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.

[pythoncoder]

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.

[jms]

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]

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.

[pythoncoder]

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

[Lysenko]

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.