@@ -54,6 +54,7 @@ asyncio and includes a section for complete beginners.
54
54
7.4 [ Testing] ( ./TUTORIAL.md#74-testing )
55
55
7.5 [ A common error] ( ./TUTORIAL.md#75-a-common-error ) This can be hard to find.
56
56
7.6 [ Socket programming] ( ./TUTORIAL.md#76-socket-programming )
57
+ 7.6.1 [ WiFi issues] ( ./TUTORIAL.md#761-wifi-issues )
57
58
7.7 [ Event loop constructor args] ( ./TUTORIAL.md#77-event-loop-constructor-args )
58
59
8 . [ Notes for beginners] ( ./TUTORIAL.md#8-notes-for-beginners )
59
60
8.1 [ Problem 1: event loops] ( ./TUTORIAL.md#81-problem-1:-event-loops )
@@ -1607,6 +1608,26 @@ I find it useful as-is but improvements are always welcome.
1607
1608
1608
1609
## 7.6 Socket programming
1609
1610
1611
+ There are two basic approaches to socket programming under ` uasyncio ` . By
1612
+ default sockets block until a specified read or write operation completes.
1613
+ ` uasyncio ` supports blocking sockets by using ` select.poll ` to prevent them
1614
+ from blocking the scheduler. In most cases it is simplest to use this
1615
+ mechanism. Example client and server code may be found in the ` client_server `
1616
+ directory. The ` userver ` application uses ` select.poll ` explicitly to poll
1617
+ the server socket. The client sockets use it implicitly in that the ` uasyncio `
1618
+ stream mechanism employs it.
1619
+
1620
+ Note that ` socket.getaddrinfo ` currently blocks. The time will be minimal in
1621
+ the example code but if a DNS lookup is required the blocking period could be
1622
+ substantial.
1623
+
1624
+ The second approach to socket programming is to use nonblocking sockets. This
1625
+ adds complexity but is necessary in some applications, notably where
1626
+ connectivity is via WiFi (see below).
1627
+
1628
+ At the time of writing (March 2019) support for TLS on nonblocking sockets is
1629
+ under development. Its exact status is unknown (to me).
1630
+
1610
1631
The use of nonblocking sockets requires some attention to detail. If a
1611
1632
nonblocking read is performed, because of server latency, there is no guarantee
1612
1633
that all (or any) of the requested data is returned. Likewise writes may not
@@ -1616,19 +1637,29 @@ Hence asynchronous read and write methods need to iteratively perform the
1616
1637
nonblocking operation until the required data has been read or written. In
1617
1638
practice a timeout is likely to be required to cope with server outages.
1618
1639
1619
- A further complication is that, at the time of writing, the ESP32 port has
1620
- issues which require rather unpleasant hacks for error-free operation.
1640
+ A further complication is that the ESP32 port had issues which required rather
1641
+ unpleasant hacks for error-free operation. I have not tested whether this is
1642
+ still the case.
1621
1643
1622
1644
The file [ sock_nonblock.py] ( ./sock_nonblock.py ) illustrates the sort of
1623
1645
techniques required. It is not a working demo, and solutions are likely to be
1624
1646
application dependent.
1625
1647
1626
- An alternative approach is to use blocking sockets with ` StreamReader ` and
1627
- ` StreamWriter ` instances to control polling.
1648
+ ### 7.6.1 WiFi issues
1649
+
1650
+ The ` uasyncio ` stream mechanism is not good at detecting WiFi outages. I have
1651
+ found it necessary to use nonblocking sockets to achieve resilient operation
1652
+ and client reconnection in the presence of outages.
1628
1653
1629
1654
[ This doc] ( https://github.com/peterhinch/micropython-samples/blob/master/resilient/README.md )
1630
1655
describes issues I encountered in WiFi applications which keep sockets open for
1631
- long periods, and offers a solution.
1656
+ long periods, and outlines a solution.
1657
+
1658
+ [ This repo] ( https://github.com/peterhinch/micropython-mqtt.git ) offers a
1659
+ resilent asynchronous MQTT client which ensures message integrity over WiFi
1660
+ outages. [ This repo] ( https://github.com/peterhinch/micropython-iot.git )
1661
+ provides a simple asynchronous full-duplex serial channel between a wirelessly
1662
+ connected client and a wired server with guaranteed message delivery.
1632
1663
1633
1664
###### [ Contents] ( ./TUTORIAL.md#contents )
1634
1665
0 commit comments