Database Reference
In-Depth Information
6. up-to-date - one of the main intents of the project was to provide a library
that could be constantly updated to the current standards, including the
various CoAP extensions that will be proposed and defined during the time;
the structure of the library was designed in order to enable and to simplify
future extensions;
7. re-usability - the same library should be re-usable for the development of other
protocols that could be defined in future, and that will share with CoAP the
same message structure, syntax, and protocol architecture; an example of such
a protocol is the CoSIP (Constrained Session Initiation Protocol), a SIP-like
signaling protocol, proposed and used in [ 25 , 26 ] for session setup and session
tear-down in constrained IoT scenarios.
In order to satisfy some of the above requirements, we chose Java as pro-
gramming language for the mjCoAP project, to take advantage of the simplicity
and portability of Java-based developments. A porting in C language of the
core of the mjCoAP library is also under development in order to fulfill also
the requirements of specific devices (for example Arduino boards) that do not
support Java programming. In particular a first C porting of mjCoAP has been
already provided and tested with Arduino devices.
4.1 mjCoAP Architecture
In order to run within constrained networks (and onto constrained devices),
UDP as been chosen as standard transport protocol for CoAP. For such a rea-
son, CoAP must support mechanisms for reliable message transmission over the
unreliable transport offered by the UDP. This results in a “layered” architec-
ture of CoAP. This is emphasized in mjCoAP where a layered architecture is
explicitly considered and implemented as depicted in Fig. 1 . The mjCoAP core
is formed by the following three sub-layers:
- Transact ion - In mjCoAP, a Transact ion is defined as the request-response
basic interaction, which corresponds to exchange of a CoAP request (a
GET
,
method) and the corresponding CoAP response
(of type 2.xx, 4.xx, or 5.xx). At CoAP client side, the transaction layer offers a
RESTful service to the user by taking charge of sending a method request and
receiving the corresponding response; similarly, at the server side, it provides
functions for receiving and processing a method request and for creating and
sending the selected response. Possible retransmissions of the same request
and/or response are dealt by the transaction layer (through the use of the
underlying Reliable transmission layer).
- Reliable transmission - It is the sublayer that is responsible for dealing with the
reliable transmissions of CoAP messages (both requests and responses); when
a message is marked as CON (i.e., its reception has to be confirmed by the
sending of an ACK message), the CON message can be passed to the Reliable
transmission layer, which will take care of the transmission, and possibly the
retransmission, of the message until a corresponding ACK message is received,
POST
,
PUT
,or
DELETE
Search WWH ::




Custom Search