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
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.
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*.
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...
I remember setting up an internal gopher server for the product group I worked in back in 19.
Grant Edwards grant.b.edwards Yow! As President I have
at to go vacuum my coin
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?
Sure you can. TLS handshakes may be slow, though, so plan for persistent connections.
That's why I mentioned that you'd need additions to your team.
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.
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.