German Shepherd (PrE) created PROTON-1021:
---------------------------------------------

Advertising

Summary: ProtonE - the Deeply Embedded ProtonC variant
Key: PROTON-1021
URL: https://issues.apache.org/jira/browse/PROTON-1021
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: Embedded C - IAR or GCC.
Reporter: German Shepherd (PrE)
Priority: Minor
Let me introduce a project I've started on 2013, when I've been tasked with a
solution on how to connect an deeply embedded Wi-Fi enabled device to MS Azure
Cloud (the plan is to connect millions of such devices).
The obvious solution was to go with ServiceBus and AMQP over TLS.
The Proton-C typically takes 230kB of RAM by default, which is way too much of
what is physically available in the embedded CPUs.
The outcome of the work is the Proton-E, based off the Proton-C library,
squeezed to run on 32kB of total RAM usage (without sacrificing any
functionality) and with a TLS on side taking addition approx. 15kB.
The "embedded" modifications are backwards applicable to the ProtonC, and this
is what I would like to introduce through this JIRA Ticket.
This work was picked up by Microsoft in mid-2014, and I have personally
cooperated with them; but I have not seen any result being provided to
community, as it seems the whole effort on their side vanished (and if not,
they stopped the cooperation - so they won't have my latest sources).
Never mind, as I have the most actual source code (as I've never stopped the
development, and I do follow every commit the ProtonC community does), none is
lost.
At this moment, before the ProtonE source gets out, let me use this ticket to
provide an assurance, that indeed the ProtonE (resp. modified ProtonC) can be
used on the constrained system, and, most importantly, it is production ready
for Azure Cloud.
*ProtonE Features*
* Low RAM footprint: total 32kB of RAM usage, for a AMQP message with 1.5kB of
payload
* Azure Cloud: Service Bus / eventHub / IoT Hub - verified
* Azure Cloud: SASL PLAIN over TLS (Active Directory) - verified
* Azure Cloud: SAS tokens (CBS) - verified
* No modifications to ProtonC API what-so-ever
* The ProtonE has been made to run and personally tested, by myself, with the
following setup: *
* CPUs: 32-bit ARM - Cortex M3 (STM32, SAM3), Cortex M4 (Atmel SAM4), Cortex M7
(Atmel SAM S70/V71), I also run this on TI Sitara with embedded RTOS
* RTOS: FreeRTOS/SafeRTOS; but primarily: expressLogic ThreadX
* TCP/IP stack: expressLogic NetX & NetX-Duo TCP/IP
* Comms: Broadcom WICED Wi-Fi solution
* TLS via Mocana NanoSSL (v6.0 or newer)
* TLS via MatrixSSL (3.6.1 or newer)
*SSL/TLS*
This is quite a huge memory hog, but should you understand it deeply, you won't
have trouble managing this.
Some numbers I've got:
* Handshake establishment: RAM usage peak is 30kB for TLS itself (handshake:
RSA)
* After the Handshake is done and the TLS tunnel is open: the TLS itself
requires 11kB of RAM (tunnel: AES)
I'm looking forward to have Microsoft to switch the Azure solely to ECC for us
(now they have RSA and ECC, and the server-side cert is solely RSA). Then the
handshake number will be even much more positive.
Once you realize that the AMQPS is the only possible scalable future for the
IoT (... hate this buzzword, BTW.), where the 95% of devices will be deeply
embedded ones, then it is obvious what role the ProtonE will play.
Best regards from CZ,
Adam N
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)