[core] COAP basic implementation.

[David Ryan <[e-mail]>]

Hi All,

Following the feedback below, I have started to develop an
implementation in Java of the COAP protocol.  The implementation uses
the proposed changes I discussed below.  In its current form it shows
a client and server implementation with a simple echo server.  It is
quite rough at the moment, but thought given the meeting coming up at
Anaheim tomorrow, it might be of interest to some.

COAP options are not currently implemented.  I will be working on them
in the coming week.  I will also be developing better JUnit tests to
improve coverage and show more examples of how the protocol could be
used.  All code is released under a BSD license.

One of the questions that came up during implementation was what is a
malformed request?  How does the server tell and under what situations
should an error response be sent?  Also, should a request have to come
from a client using the COAP port, or should the server send responses
to the client port that sent it?

You can find the download under Colony COAP near the bottom of
http://www.einet.com.au/Downloads

Comments and feedback appreciated.

Regards,
David.


On Fri, Mar 19, 2010 at 10:01 AM, David Ryan <[e-mail]> wrote:
> Hi All,
>
> I sent the following questions and feedback to Brian and Zach who
> suggested I forward this to the list for further discussion.  I won't
> be at the meeting in Anaheim next week, so here's my input.
>
> First off, a question regarding the compression of the protocol.
> You've managed to compress the header into 4 bytes.  Obviously the
> size of the header is going to be important.  In the priority list of
> features, is this the most important?  Would another byte or two hurt?
>
> I notice between Chopan and COAP you've dropped the magic number
> headers.  This must have been a conscious decision. I would have liked
> to see a one byte magic value to identify the packet or TCP stream.
> This would at least give a server a chance to throw away the request
> if it receives a bad message.
>
> In regard to version.  Two bits only leaves four possible versions.
> Extending this to 4 bits would at least extend this to 16 versions.
> This goes back to the original point regarding size of header.
>
> Back in 2008 I did a thought experiment on a binary REST based
> protocol.  Details available at:
>
> http://blog.livemedia.com.au/search?updated-min=2008-01-01T00%3A00%3A00%2B11%3A00&updated-max=2009-01-01T00%3A00%3A00%2B11%3A00&max-results=7
>
> Many of the elements are not applicable to COAP, but there might be
> one or two features I developed which could be worth discussing.
>
> One element of this through experiment was to include a "slotsAvailable"
> in the response.  As the "transactionid" field allows multiple
> requests to be sent to a single recipient, the "slotsAvailable" in the
> response allows a client to limit the number of requests sent.  I'd
> suggest 4 bits in the response.  If the server can handle more than 16
> requests it can return 16 in all responses.  A small device might
> return 1 at all times.
>
> Another concept I thought about was to have a bit field for protocol
> features.  This may not be applicable in this case, however, something
> to put on the back burner.  The idea is that a small device might only
> respond to a limited set of features (or options).  A bit field can be
> used to identify in the request which features are being used and in
> the response what features the server can handle.
>
> I was also surprised that the protocol doesn't include the URI path in
> the main part of the header.  I must admit I'm still trying to
> understand how the index based approach to URI paths will work in your
> proposal.
>
> I tried taking your proposal and combined it with a few of the above
> changes and came up with the following:
>
> Packet
>  preamble/magic  (1 byte)
>
>  version (4 bits)
>  features (4 bits)
>
>  response (1 bit)
>  options (1 bit)
>  asynchronous (1 bit)
>  locationType (1 bit)     (0 URI location field enabled, 1 location
> specified in options)
>  method/slots (4 bits)  (method type in request/slots available in response)
>
>  transactionId (16 bits)
>
>  location (URI location if locationType 0)
>
>  options length (8 bits - length)
>  ... options ...
>
>  payload length (variable length int)
>  ...payload data...
>
>
> The base header in this case is 5 bytes instead of the 4 bytes.
>
> I also suggested that the number of options is at the start of the
> options list.  This allows the server to quickly decide if the packet
> can be handled and all the option list can be processed.  In a
> constrained device only a selected number of options could be
> processed.  This removes the need for the 0 byte end of options byte.
>
> I have also used a variable length integer for the payload.  This is
> to allow the protocol to move to TCP with larger packets.
>
> Regards,
> David.
>
>
> On Tue, Mar 2, 2010 at 8:30 AM, Zach Shelby <[e-mail]> wrote:
>> http://www.ietf.org/id/draft-shelby-core-coap-00.txt
>>
>> Here is a very early draft of a CoAP protocol specification based on the requirements and initial ideas formulated in draft-shelby-core-coap-req-00 and the previous work by Brian in draft-frank-6lowapp-chopan. Looking forward to lots of good discussion around CoAP, and as you can see from all the TODOs and TBDs - lots of WG stuff to do here!
>>
>> At the same time I'd like to request a time-slot to present this in Anaheim.
>>
>> Zach
>>
>> Begin forwarded message:
>>
>>> From: IETF I-D Submission Tool <[e-mail]>
>>> Date: March 1, 2010 23:24:35 GMT+02:00
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: New Version Notification for draft-shelby-core-coap-00
>>>
>>>
>>> A new version of I-D, draft-shelby-core-coap-00.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository.
>>>
>>> Filename:      draft-shelby-core-coap
>>> Revision:      00
>>> Title:                 Constrained Application Protocol (CoAP)
>>> Creation_date:         2010-03-01
>>> WG ID:                 Independent Submission
>>> Number_of_pages: 17
>>>
>>> Abstract:
>>> This document specifies the Constrained Application Protocol (CoAP),
>>> a RESTful protocol for use with constrained networks and nodes.  CoAP
>>> easily translates to HTTP for integration with the web while meeting
>>> specialized requirements such as multicast support, very low overhead
>>> and simplicity for constrained environments.
>>>
>>>
>>>
>>> The IETF Secretariat.
>>>
>>>
>>
>> --
>> http://www.sensinode.com
>> http://zachshelby.org - My blog "On the Internet of Things"
>> http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
>> Mobile: [phone]
>>
>> Zach Shelby
>> Head of Research
>> Sensinode Ltd.
>> Kidekuja 2
>> 88610 Vuokatti, FINLAND
>>
>> This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.
>>
>>
>>
>>
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
>>
>