client_server example rewrite to uasyncio v3. #43
Comments
|
It needs tidying up to conform with the new syntax, but uasyncio V3 does support the old event loop approach. A quick test on a Pyboard D, running the server under the Unix build on my PC, proves that the code does run under V3. I will produce an updated version in due course. In answer to your general query, StreamWriter and StreamReader are (in my view) still the way to do this. @damien plans improvements to the underlying select/poll mechanism to improve the performance of stream I/O, so applications using it should automatically benefit. |
|
I have ported this to V3 in the directory v3/as_drivers/client_server. This is alpha code and is not yet documented: I've tested it with the client running on a Pyboard D and the server running on the Unix build. I believe it is still portable, but need to find time to test it. The server now uses asyncio.start_server() which I believe has improved since V2. It simplifies the code. The server code may change: asyncio.Server is evidently designed to be used in an asynchronous context manager. If I can figure this out I may make this change. I'd be grateful for any observations, bugs, ideas or test reports. |
|
Sorry for "close" and "reopen" this issue, was just a wrong click. Thank you for the port to v3, I will test soon as possible :) Another question: is easy to add SSL support to this client_server example, to be a secure TCP/IP connection? Thank you. |
|
I don't know. I've only tested this demo on a local network. There have been issues around running TLS on nonblocking sockets. My understanding is that this works on Pyboard D but may not on ESPx targets which use a different network stack. But I may be out of date and I'd suggest a forum search or query on that one. I'm an electronics guy rather than a network programmer or security expert. However I have doubts over the wisdom of running TLS on bare metal targets for reasons discussed here. |
But MicroPython are not running as baremetal, it runs as a task of FreeRTOS, right?
Sorry, could you to clarify to me, is this link correct? it go to micropython-iot, where has no "discussions", no threads. Thank you so much. |
That depends on the platform. It is true for ESP32, but on Pyboards (1.x and D) it runs on baremetal, also on many other platforms. But bare metal isn't the issue here. Lazy writing on my part. I evidently did a poor job of explaining my point. I have doubts about the wisdom of IOT devices accessing the internet for reasons I tried to present in the link. I prefer an architecture in which the IOT devices communicate with a server using a simple socket-like interface. An interface designed to be resilient in the face of WiFi outages. The server, which can be something cheap like a Raspberry Pi, communicates with the internet. It uses TLS. Because it runs Linux it can be kept updated and secure. The multiple IOT nodes do not need constant security upgrades because their communication protocol is simple and limited. What can an attacker do with a JSON string? Unless your application sends executable code (NO) it's easy to trap and reject malformed strings. Aside from security, TLS is demanding of resources. Further, WiFi outages are common. WiFi connected PC's hide brief outages from the user but "bare metal" and ESP32's do not. Here brief outages occur about once an hour. Any communications operating over WiFi need to take account of this. For example the official MQTT library is utterly broken in this regard. I don't know the implications of this for long term connections to internet resources. If your application periodically sets up a link, uses it, and shuts it down it will probably be OK. If you need to keep it open 24/7 I have my doubts. |
|
Hi @peterhinch
Just to explain your scenario: ======== no secure ======== secure ======== I understand you, but with this scenario we have many problems:
I agree your scenario if we can use ESP32 instead RPI (may be can be another microcontroller) as Gateway, but even in this scenario is essential SSL between iot devices and gateway (ESP32): ======== JSON-RPC ================ JSON-RPC ============== This scenario above I already using (except secure - SSL) as tests, and is my goal. I'm using a clean and light JSON-RPC over a TCP/IP socket between ESP32 devices and ESP32 Gateway.
Resources actually is not a problem for all microcontrollers, like ESP32 where is the default (and cheap) come with 4MB RAM on ESP32-WROVER modules.
I understand you, but is a developer responsibility to put a "ping" to test frequently if connection is OK. Actually I have a ESP32 connected to an electric motor and ESP32 sending information (voltage/current/etc) to the server/cloud over a WiFi AcessPoint (Dlink) 24x7. The connection between ESP32 and Server is a persistent connection, NO sets up a link, uses it, and shuts it down, because Server can send data to change motor configuration or acting on motor (sending a command) to ESP32 shutdown the motor, for example, so connection between ESP32 and Server need to be always open, all the time. This already working 8 months (24x7) without problem. When a "ping" or a send JSON-RPC message (with ACK) do not receive answer, I do in ESP32 a reconnect to WiFi. Follow the scenario: About MQTT 24x7, I have no experience, but I think is possible to do a "ping" using MQTT too, right? I could tell you infinite applications/solutions where is no possible to use a gateway for IOT devices, I mean, where IoT devices need to be connected directly to the server/cloud with secure mode, like as a tracker (connected via WiFi/4G(using PPPoS - I'm using it)). So that is clear that we need to add a SSL on TCP/IP socket and use Writer/StreamReader socket over that secure socket. That is the perfect, perfect. Please, think about that :) Thank you so much! |
|
When it comes to security we need to be clear about the threat. I agree that my IOT solution does not protect against interception of the information flowing between the server and the ESP's. In many cases the data is just sensor values and it simply doesn't matter. But I agree that there is a case for TLS on the WiFi link if data is confidential. The IOT solution just uses a socket, so TLS could be used if the problem of TLS on nonblocking sockets were fixed. A reason for the IOT design is to protect against the risk where unpatched, Internet-connected devices are taken over by an attacker. Since the IOT solution exchanges only JSON strings it is hard to see how this could occur. I believe that internet-connected devices should regularly be patched with the latest security updates. This is more practical with a Linux based SBC than with a host of remote devic 8606 es. As for the pricing of such devices worldwide, I take your point. The power consumption of one of the simpler Pi's is about 5W. MQTT is another option which I have addressed. I have tested this with TLS on a Pyboard D. The last time I tried TLS on ESPx it didn't work owing to the nonblocking socket issue. This is a major issue which (as far as I know) has not been fixed. Search for TLS in this discussion. Until the maintainers fix this issue, the use of TLS on ESPx with uasyncio seems impractical. |
|
Closing as TLS issues have now been fixed. |
Uh oh!
There was an error while loading. Please reload this page.
Hi Piter!
Two questions:
Thank you so much :)
The text was updated successfully, but these errors were encountered: