[ell-i-developers] Re: Initial spec for a CoAP API

  • From: Pekka Nikander <pekka.nikander@xxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Thu, 27 Feb 2014 14:10:49 +0200

I pushed now the work-in-progress into a separate feature-coap-wip branch:


It is still far from working, but now the skeleton is missing just a couple of 
bones any more.


On 2014–02–25, at 22:26 , Pekka Nikander <pekka.nikander@xxxxxx> wrote:

> I have now a preliminary skeleton for the CoAP API and some initial code for 
> the implementation; far from ready though.
> For the API, the idea is to define CoAP URLs at compile time, storing all the 
> data structures in the flash, in a manner similar to how we handle peripheral 
> initialisation now.
> As an example of a temperature sensor, the API might look like the following:
> static void temp_sensor_get(char *buffer, const char *format) {
>    iprintf(buffer, format, ...);
> }
> DEFINE_COAP_GET_URL("/sensors/temp", temp_sensor_get, 
>    { COAP_FORMAT_TEXT_PLAIN,       "%d" },
>    { COAP_FORMAT_APPLICATION_JSON, "{ \"temperature\": \"%d\" }");
> The idea is that this compiles into a statically allocated data structure 
> that the linker makes available to the CoAP protocol part that handles GET 
> urls.  
> The GET handler will go through all of the GET URL data structures (linearly 
> at this phase), until it finds a match with the requested URL.  When a match 
> is found, it calls a callback function (temp_sensor_get in this case), 
> passing it a pointer to a buffer where the result should be formatted (a 
> pointer to the right place in the packet), and a pointer to a template for 
> formatting the result.  The implementation may support multiple content 
> formats, as can be seen.  The first one is the default one if the client does 
> not specify what format it would like or if the requested format is not 
> available.  
> The callback function must not block.  In the first implementation it will 
> run in the interrupt context; we will move the processing to the threading 
> context only once we'll have thread support in the new runtime.  Even once 
> moved to a threading context, it SHALL produce the result within CoAP 
> ACK_TIMEOUT, which is currently 2 seconds.
> I don't like much the idea that we must include iprintf() for this to work, 
> but so far I haven't figured out any better idea on how to format the 
> results, either.  Of course, the API does not necessitate the use of 
> iprintf(), but without it e.g. generating JSON or XML replies is somewhat 
> complicated and may produce so large code that using iprintf() is well 
> justified.  But YMMV; opinions sought.
> The PUT API is likely to be very similar, but I haven't yet been able to 
> figure out what is the best way to parse the content.  sscanf() is too bulky 
> and insecure.  I think I will leave that to the handler so that it can parse 
> in an ad-hoc manner, most probably only supporting plain text messages in an 
> application-specific format.  Good ideas here would be very welcome.
> I'm not planning to support POST or DELETE methods.
> Comments?  Suggestions for improvements?
> If you need more background, please have a look at these:
> https://ietf.org/doc/rfc6690/?include_text=1
> https://ietf.org/doc/draft-ietf-core-coap/?include_text=1
> https://ietf.org/doc/draft-bormann-core-roadmap/?include_text=1
> --Pekka
> On 2014–02–25, at 19:22 , Pekka Nikander <pekka.nikander@xxxxxx> wrote:
>> I have now a skeleton written for UDP and IP; I'm writing a skeleton for 
>> CoAP.
>> This very first version will *NOT* be compatible with the Arduino Ethernet 
>> library, but will be more minimal, with all sockets and CoAP URLs 
>> compile-time allocated.  In this way it consumes less RAM and flash.  And is 
>> easier to write.
>> I expect to have a first working but untested version ready on Thursday; 
>> perhaps already tomorrow.
>> ARP, ICMP and DHCP are still completely missing, but we can test the stack 
>> without them.
>> --Pekka

Other related posts: