"Device-to-smartphone" and "smartphone-to-device" technologies

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!! 
 Click to see the full signature
Reply to
Grant Edwards
Loading thread data ...

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 to
Rob Gaddi

On 2018-12-13 Rob Gaddi wrote in comp.arch.embedded:

It does :-)

formatting link

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 to
Stef

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

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

:)

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 
 Click to see the full signature
Reply to
Grant Edwards

What PK crypto are you using? Some of the EC versions should be better than that.

Reply to
Clifford Heath

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!! 
 Click to see the full signature
Reply to
Grant Edwards

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 to
pozz

Of course SSL is much slower. Otherwise, why would people spend money on hardware crypto accelleration?

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                
 Click to see the full signature
Reply to
Grant Edwards

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.

You're welcome!

--
mikko
Reply to
Mikko OH2HVJ

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.