Hi there,

We have recently had the opportunity to utilize Proton on embedded devices to 
talk to Azure.  The class of embedded devices we are working with require some 
strict design constraints on the AMQP library we can use:

*         Library must be AMQP 1.0 compatible

*         Library must run on embedded devices running a micro RTOS, TCP/IP and 

*         Library should avoid heap fragmentation

*         Library RAM use must be less than 25K

*         Library Flash use must be less than 75k

These requirements are not met by Proton out of the box, but we do think they 
align with the Proton roadmap to support this class of devices.

In order to accomplish these goals, we are proposing to alter some of the 
underlying Proton-C architecture.  Here is an overview of the changes we are 

Target Micro RTOS, TCP/IP, and SSL - Introduce a porting layer to provide 
abstractions for required RTOS constructs.  These constructs are limited to 
basic constructs- threads, queues, semaphores.  Some changes may be necessary 
to adapt the socket and network interface to RTOS requirements and improve 
portability across RTOS and network stacks.  Devices running without an RTOS 
are not supported.  A porting layer provides abstractions for the required 
Embedded SSL constructs.

Memory Allocation and Management - To make more efficient use of the available 
memory and avoid fragmentation, calls to malloc() may be replaced by specially 
tailored memory allocation routines and/or block pools.

Limited Protocol Features - In order to meet RAM and flash usage targets, 
protocol features can be limited.  The allowable limits are set to assure the 
implementation remains 1.0 compatible.  These limits will be documented.

Initially, we would target the following platforms and libraries:

*         ThreadX
*         FreeRTOS

TCP/IP stacks:
*         NetX
*         LwIP

SSL Libraries:
*         Mocana
*         Matrix

Although we would prefer to contribute these changes back to the Proton-C 
source tree, we think these changes would radically alter the Proton-C codebase 
as it stands now.  A better solution may be to introduce a new class of Proton- 
call it Proton Embedded or Proton-e.  We have already kicked off this work and 
would like to contribute these changes back to the community, most likely in a 
branch so that the community can review the code thoroughly before deciding on 
a final home.

Would there be interest in this work added to the Proton project?

Chris Busbey
Senior Program Manager
Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation

Reply via email to