Database Reference
In-Depth Information
specifying the type of messages that a user of the Messaging layer is interested
to listen to.
Note that the mjCoAP user is usually expected to interact only with the
Transact ion layer, which is therefore responsible for interacting with all under-
lying functions and corresponding sub-layers.
In addition to the previously described classes implementing the various
CoAP sub-layers, the core mjCoAP also includes classes for dealing with CoAP
messages. These classes are: BasicCoapMessage , BasicCoapMessageFactory ,and
CoapOption .
The listed classes form the core of the mjCoAP stack in a very compact
and easy-to-use manner. Note that this core part of mjCoAP implements only
the basic CoAP protocol including the message syntax, transmission, reception
and request-response interactions, regardless the specific meaning of a request
method, a response, and regardless the various possible CoAP header fields
(CoAP Options) that form a CoAP message. This part (formed by all previously
listed classes an interfaces) forms the core mjCoAP package org.zoolu.coap.core .
All other CoAP specific functions, such as header fields, and protocol behav-
ior, are implemented within the additional packages org.zoolu.coap.message and
org.zoolu.coap.option .
The separation between the core of the CoAP protocol and all other specifica-
tions has the advantage that possible future CoAP-like protocols (i.e., protocols
that might reuse the CoAP message format and the basic protocol architecture)
can be easily implemented based on the same mjCoAP core. In [ 26 ], we pro-
posed a Constrained Session Initiation Protocol (CoSIP), based on CoAP, that
has been also (easily) implemented through the mjCoAP stack, and used to build
a P2P overlay [ 27 ].
In order to validate mjCoAP, extensive compatibility tests has been carried
on interacting with other CoAP implementations. In particular, interoperability
tests have been successfully done with Californium [ 18 ], Erbium [ 21 ], and with
Copper [ 22 ] libraries.
4.2 Using mjCoAP
In order to provide an ecient and non-blocking behavior (which can be prefer-
able, for instance, in mobile applications), mjCoAP is designed to follow an
asynchronous style: methods that imply communication terminate immediately
and the result is then notified to the application through cal lback methods.
There are two main typical ways to use mjCoAP into a Java application: (i) at
the Transact ion layer and (ii) at the Messaging layer. The choice between them
depends on the degree of abstraction that best fits the needs of the developer.
For instance, the low-level functionalities provided by the Messaging layer are
best suited to applications that might require simple communication between
endpoints. Regardless of the layer that is going to be used for development, the
fundamental class that always needs to be present in any mjCoAP application
is the CoapProvider .The CoapProvider is the basic communication enabler that
is responsible for sending and receiving CoAP messages over a datagram socket
Search WWH ::




Custom Search