> Il 12/12/2018 07:34, Mikko OH2HVJ ha scritto:
> Do you think a simple Cortex-M3 running FreeRTOS/superloop with lwip
> TCP/IP stack is not sufficient? This hw actually runs a HTTP server
> without big issues.
Sure you can. TLS handshakes may be slow, though, so plan for persistent
connections.
> Any real suggestions? I tried to read Amazon Web Services and Google
> Cloud Platform, but sincerely I lost the way.
That's why I mentioned that you'd need additions to your team.
>> or my own MQTTS/AMQPS server with my own server.
> Do you mean a MQTT broker? So you imagine that the app on the
> smartphone is a MQTT client, as the device?
Yep, if you just can have your own server. In addition you can
add application that does something when the smartphone is not
connected. And a lot of other stuff.
>> -Mobile app to connect through the cloud - there are tools that allow
>> reusing web development - not the best ones, but possible.
> Yes. The mobile app should connect to the cloud through MQTT or
> similar protocols, right?
Smartphones typically do not have the constraints MQTT was designed for,
so you can use 'whatever'. On that part you need to think about the
battery consumption so that the users will not be pissed off.
> Thank you very much for your post. Those are precious info.
You're welcome!
--
mikko
Reply by Grant Edwards●December 14, 20182018-12-14
On 2018-12-14, pozz <pozzugno@gmail.com> wrote:
> SSL is a must, I know. And I know I can integrate mbedTLS library on
> top of lwip. This is one of a next project.
>
> I don't know if SSL is much more slower than pure HTTP. I hope no,
> of course.
Of course SSL is much slower. Otherwise, why would people spend money
on hardware crypto accelleration?
> I hope MQTTS experience is much more fast than browsing web pages
> over HTTPS protocol. MQTTS should be a persisten connection.
The persistent connection will help a lot. The public-key stuff
during hanshaking takes a _lot_ of CPU. I would guess that the amount
of data being transferred via MQTT is also much smaller.
--
Grant Edwards grant.b.edwards Yow! HAIR TONICS, please!!
at
gmail.com
Reply by pozz●December 14, 20182018-12-14
Il 13/12/2018 19:09, Rob Gaddi ha scritto:
> On 12/13/18 4:51 AM, pozz wrote:
>> Il 12/12/2018 07:34, Mikko OH2HVJ ha scritto:
>
>>> Serverless is really nice approach for cloud, but finding true
>>> experience in that field is difficult.
>>>
>>> If I were to create a small scale mobile-controlled IoT device, I
>>> would pick
>>> -Linux SOM or ESP32 (if you've got mains power - battery is more
>>> difficult!)
>>
>> Do you think a simple Cortex-M3 running FreeRTOS/superloop with lwip
>> TCP/IP stack is not sufficient? This hw actually runs a HTTP server
>> without big issues.
>>
>
> Yeah, but it's not running HTTPS.� I think a CM3 would be woefully
> outclassed by having to slap SSL on top of things, and if you're not
> securing your traffic you're adding to the Internet of Crap problem.
SSL is a must, I know. And I know I can integrate mbedTLS library on top
of lwip. This is one of a next project.
I don't know if SSL is much more slower than pure HTTP. I hope no, of
course. Anyway, regarding about the cloud service, I could think to move
all the web pages (.html, .java, .css, .png, ...) on a public server and
put on only a mechanism to retrieve dynamic data (.json) from the device
through other protocols (MQTTS or similar).
My idea is:
- the device open a connection with my *own* SERVER1, maybe MQTTS
- SERVER2 is a normal Web hosting service
- apps on smartphone are web viewer that connects to SERVER2, when the
user wants to connect to his home
- .json HTTP requests are processed in SERVER2 and decoded in another
HTTPS request to SERVER1 that exposes a proprietary API
- SERVER1 decodes the request from SERVER2, extract the device ID and
type of request and transcode to MQTTS
- the answer from the device goes in the opposite direction
I hope MQTTS experience is much more fast than browsing web pages over
HTTPS protocol. MQTTS should be a persisten connection.
I'm using now LPC1769 from NXP. I know there are MCUs with crypto
engine: STM32F2, K6x, ...
Maybe this mess is faster on those MCUs. Any experience?
Reply by Grant Edwards●December 13, 20182018-12-13
On 2018-12-13, Clifford Heath <no.spam@please.net> wrote:
> What PK crypto are you using? Some of the EC versions should be better
> than that.
I'd have to check, but with common clients it's always one of the EC
ones.
--
Grant Edwards grant.b.edwards Yow! The PINK SOCKS were
at ORIGINALLY from 1952!!
gmail.com But they went to MARS
around 1953!!
Reply by Clifford Heath●December 13, 20182018-12-13
On 14/12/18 5:59 am, Grant Edwards wrote:
> On 2018-12-13, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
>> On 12/13/18 4:51 AM, pozz wrote:
>>
>>> Do you think a simple Cortex-M3 running FreeRTOS/superloop with lwip
>>> TCP/IP stack is not sufficient? This hw actually runs a HTTP server
>>> without big issues.
>>
>> Yeah, but it's not running HTTPS. I think a CM3 would be woefully
>> outclassed by having to slap SSL on top of things, and if you're not
>> securing your traffic you're adding to the Internet of Crap problem.
>
> I run HTTPS (and other SSL-based stuff) on a 130MHz CM3, and
> connection establishment is where it hurts. It takes 1-2 seconds for
> the generation of the ephemeral key and subsequent handshaking. After
> that, the actual encryption/decryption is fine. For HTTPS, make sure
> you support persistent connections.
What PK crypto are you using? Some of the EC versions should be better
than that.
Reply by Grant Edwards●December 13, 20182018-12-13
On 2018-12-13, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
>
>> I run HTTPS (and other SSL-based stuff) on a 130MHz CM3, and
>> connection establishment is where it hurts. It takes 1-2 seconds for
>> the generation of the ephemeral key and subsequent handshaking. After
>> that, the actual encryption/decryption is fine. For HTTPS, make sure
>> you support persistent connections.
>>
>> If only there was a way to tell a browser not to try open 8 parallel
>> HTTPS connections at a time, pages would load a hell of a lot
>> faster...
>
> Huh, I'm surprised that even the later encrypt/decrypt hold up. Is said
> micro doing much else at the same time?
Sure. There are up to 32 serial ports being serviced at the same
time. They have priority. The throughput on the encrypted TCP
connection is a lot lower than a cleartext one, but the difference
isn't that noticable for normal web page stuff *once the connections
are established*.
> My firmware guy has had the same complaint on parallel connections.
> The modern web is completely unable to deal with the idea that the
> server you're communicating with isn't a cluster of 16 AWS instances
> with effectively infinite memory.
Exactly.
If there was just an HTTP header you could set in that first response
to tell the browser that there's only one CPU here: the more
connections you open, the longer the whole thing is going to take...
> Wonder whether gopher:// still works...
:)
I remember setting up an internal gopher server for the product group
I worked in back in 19<mumble>.
--
Grant Edwards grant.b.edwards Yow! As President I have
at to go vacuum my coin
gmail.com collection!
Reply by Stef●December 13, 20182018-12-13
On 2018-12-13 Rob Gaddi wrote in comp.arch.embedded:
>
> Wonder whether gopher:// still works...
It does :-)
https://en.wikipedia.org/wiki/Gopher_(protocol)
If you have lynx working, you could start here:
> lynx gopher.floodgap.com:70
But there are more browsers that support Gopher.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
Man's reach must exceed his grasp, for why else the heavens?
Reply by Rob Gaddi●December 13, 20182018-12-13
On 12/13/18 10:59 AM, Grant Edwards wrote:
> On 2018-12-13, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
>> On 12/13/18 4:51 AM, pozz wrote:
>>
>>> Do you think a simple Cortex-M3 running FreeRTOS/superloop with lwip
>>> TCP/IP stack is not sufficient? This hw actually runs a HTTP server
>>> without big issues.
>>
>> Yeah, but it's not running HTTPS. I think a CM3 would be woefully
>> outclassed by having to slap SSL on top of things, and if you're not
>> securing your traffic you're adding to the Internet of Crap problem.
>
> I run HTTPS (and other SSL-based stuff) on a 130MHz CM3, and
> connection establishment is where it hurts. It takes 1-2 seconds for
> the generation of the ephemeral key and subsequent handshaking. After
> that, the actual encryption/decryption is fine. For HTTPS, make sure
> you support persistent connections.
>
> If only there was a way to tell a browser not to try open 8 parallel
> HTTPS connections at a time, pages would load a hell of a lot
> faster...
>
Huh, I'm surprised that even the later encrypt/decrypt hold up. Is said
micro doing much else at the same time?
My firmware guy has had the same complaint on parallel connections. The
modern web is completely unable to deal with the idea that the server
you're communicating with isn't a cluster of 16 AWS instances with
effectively infinite memory.
Wonder whether gopher:// still works...
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
Reply by Grant Edwards●December 13, 20182018-12-13
On 2018-12-13, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
> On 12/13/18 4:51 AM, pozz wrote:
>
>> Do you think a simple Cortex-M3 running FreeRTOS/superloop with lwip
>> TCP/IP stack is not sufficient? This hw actually runs a HTTP server
>> without big issues.
>
> Yeah, but it's not running HTTPS. I think a CM3 would be woefully
> outclassed by having to slap SSL on top of things, and if you're not
> securing your traffic you're adding to the Internet of Crap problem.
I run HTTPS (and other SSL-based stuff) on a 130MHz CM3, and
connection establishment is where it hurts. It takes 1-2 seconds for
the generation of the ephemeral key and subsequent handshaking. After
that, the actual encryption/decryption is fine. For HTTPS, make sure
you support persistent connections.
If only there was a way to tell a browser not to try open 8 parallel
HTTPS connections at a time, pages would load a hell of a lot
faster...
--
Grant Edwards grant.b.edwards Yow! I represent a
at sardine!!
gmail.com
Reply by Rob Gaddi●December 13, 20182018-12-13
On 12/13/18 4:51 AM, pozz wrote:
> Il 12/12/2018 07:34, Mikko OH2HVJ ha scritto:
>> Serverless is really nice approach for cloud, but finding true
>> experience in that field is difficult.
>>
>> If I were to create a small scale mobile-controlled IoT device, I
>> would pick
>> -Linux SOM or ESP32 (if you've got mains power - battery is more
>> difficult!)
>
> Do you think a simple Cortex-M3 running FreeRTOS/superloop with lwip
> TCP/IP stack is not sufficient? This hw actually runs a HTTP server
> without big issues.
>
Yeah, but it's not running HTTPS. I think a CM3 would be woefully
outclassed by having to slap SSL on top of things, and if you're not
securing your traffic you're adding to the Internet of Crap problem.
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.