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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: "Device-to-smartphone" and "smartphone-to-device" technologies
Quoted text here. Click to load it

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!!
We've slightly trimmed the long signature. Click to see the full one.
Re: "Device-to-smartphone" and "smartphone-to-device" technologies
On 12/13/18 10:59 AM, Grant Edwards wrote:
Quoted text here. Click to load it

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.

[OT] Gopher
On 2018-12-13 Rob Gaddi wrote in comp.arch.embedded:
Quoted text here. Click to load it

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?

Re: "Device-to-smartphone" and "smartphone-to-device" technologies
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

:)

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
We've slightly trimmed the long signature. Click to see the full one.
Re: "Device-to-smartphone" and "smartphone-to-device" technologies
On 14/12/18 5:59 am, Grant Edwards wrote:
Quoted text here. Click to load it

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

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

Quoted text here. Click to load it

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!!
We've slightly trimmed the long signature. Click to see the full one.
Re: "Device-to-smartphone" and "smartphone-to-device" technologies
Il 13/12/2018 19:09, Rob Gaddi ha scritto:
Quoted text here. Click to load it

Quoted text here. Click to load it

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?



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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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                
We've slightly trimmed the long signature. Click to see the full one.
Re: "Device-to-smartphone" and "smartphone-to-device" technologies

Quoted text here. Click to load it

Sure you can. TLS handshakes may be slow, though, so plan for persistent
connections.  

Quoted text here. Click to load it

That's why I mentioned that you'd need additions to your team.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

You're welcome!

--
mikko

Site Timeline