Database Reference
In-Depth Information
and (iii) it is compatible with duty-cycled devices, which sleep for consistent
periods of time and, therefore, might not keep a connection alive.
UDP provides a low-overhead transport for CoAP messages, making it more
suited to communication between constrained devices. However, the lightweight
nature of UDP introduces some limitations (which are intrinsically managed by
TCP instead) that must be addressed at the application layer, such as relia-
bility (retransmission) and request/response matching. CoAP messages (either
requests or responses) can be marked as Confirmable (
CON
) or Non-confirmable
(
NON
). Reliable communication is achieved by using
CON
messages. When a
CON
)
message from the server (prior to a retransmission timeout with exponential
back-off) to confirm the successful delivery of the request. If this does not hap-
pen, the client retransmits the request to server. Similarly, when the server sends
a response in reply of a
request is sent, the client expects to receive an Acknowledgement (
ACK
CON
request, it includes it in a
CON
message: it expects
to receive an
message (prior to a retransmission timeout with exponen-
tial back-off) to confirm the successful delivery of the response. Should not this
happen, the server retransmits the response to server. A reliable transaction is
therefore achieved by a three-message transaction, consisting of an initial
ACK
CON
request, a server
messages are used for unreliable
transmissions, that is, for requests and responses that must not have guaranteed
delivery. The response to a
ACK
,andaclient
ACK
.
NON
NON
NON
request is returned in a
message.
When a
CON
request is sent, the server can respond with two different
responses.
- piggy-backed response , if the server can respond immediately, the server
includes the response in the
message that acknowledges the request;
- separate response , if the server is unable to response immediately, the server
sends the
ACK
message that acknowledges the request immediately and sends
the response later in a
ACK
CON
message.
CoAP communications are secured using DTLS [ 10 ], similarly to HTTP with
TLS [ 11 ].
2.2 Proxying
CoAP has been designed to easily map to HTTP in order to provide a transparent
integration with the Web. A “ cross-proxy ” is a network element that provides
protocol translation functionalities, in order to allow the integration between
HTTP and CoAP endpoints. Cross-proxies are crucial elements to guarantee
maximum interoperability between the Internet and the Internet of Things and
represent the contact point between them. The use of proxies can also have other
advantages, such as the possibility to hide the details of the constrained network
to external clients and to shield constrained nodes from being directly accessible
by Internet hosts (for instance, by providing caching), in order to achieve better
security (e.g., from DoS attacks) and minimize energy consumption (by prevent-
ing too many requests from being sent to constrained nodes). HTTP clients can
Search WWH ::




Custom Search