Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28415 > unrolled thread

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

Back to article view | Back to comp.arch.embedded

Contents

  "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-09 23:49 +0100
    Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-10 12:04 +0200
      Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-10 11:33 +0100
        Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-10 14:09 +0200
          Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-10 14:51 +0100
            Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-10 22:50 +0200
              Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-11 14:27 +0100
                Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-11 16:50 +0200
                  Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-11 23:34 +0100
                    Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-12 02:26 +0200
    Re: "Device-to-smartphone" and "smartphone-to-device" technologies Theo <theom+news@chiark.greenend.org.uk> - 2018-12-10 14:34 +0000
      Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-10 23:05 +0100
        Re: "Device-to-smartphone" and "smartphone-to-device" technologies Theo <theom+news@chiark.greenend.org.uk> - 2018-12-11 11:58 +0000
          Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-11 14:36 +0100
    Re: "Device-to-smartphone" and "smartphone-to-device" technologies lasselangwadtchristensen@gmail.com - 2018-12-10 13:17 -0800
      Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-10 23:05 +0100
    Re: "Device-to-smartphone" and "smartphone-to-device" technologies Robert Wessel <robertwessel2@yahoo.com> - 2018-12-10 20:18 -0600
    Re: "Device-to-smartphone" and "smartphone-to-device" technologies Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2018-12-12 08:34 +0200
      Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-13 13:51 +0100
        Re: "Device-to-smartphone" and "smartphone-to-device" technologies Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-12-13 10:09 -0800
          Re: "Device-to-smartphone" and "smartphone-to-device" technologies Grant Edwards <invalid@invalid.invalid> - 2018-12-13 18:59 +0000
            Re: "Device-to-smartphone" and "smartphone-to-device" technologies Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-12-13 11:17 -0800
              [OT] Gopher Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2018-12-13 21:00 +0100
              Re: "Device-to-smartphone" and "smartphone-to-device" technologies Grant Edwards <invalid@invalid.invalid> - 2018-12-13 20:37 +0000
            Re: "Device-to-smartphone" and "smartphone-to-device" technologies Clifford Heath <no.spam@please.net> - 2018-12-14 08:12 +1100
              Re: "Device-to-smartphone" and "smartphone-to-device" technologies Grant Edwards <invalid@invalid.invalid> - 2018-12-13 21:46 +0000
          Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-14 09:17 +0100
            Re: "Device-to-smartphone" and "smartphone-to-device" technologies Grant Edwards <invalid@invalid.invalid> - 2018-12-14 15:18 +0000
        Re: "Device-to-smartphone" and "smartphone-to-device" technologies Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2018-12-15 18:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#28452

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            

[toc] | [prev] | [next] | [standalone]

#28453

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.

[toc] | [prev] | [next] | [standalone]

#28454 — [OT] Gopher

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?

[toc] | [prev] | [next] | [standalone]

#28455

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!

[toc] | [prev] | [next] | [standalone]

#28456

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.

[toc] | [prev] | [next] | [standalone]

#28457

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

[toc] | [prev] | [next] | [standalone]

#28458

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?

[toc] | [prev] | [next] | [standalone]

#28459

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            

[toc] | [prev] | [next] | [standalone]

#28460

pozz <pozzugno@gmail.com> writes:

> 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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web