remove unneeded image
[skm-ma-ws1314.git] / sec-discussion.tex
1 \section{Discussion}\label{sec:discussion}
2
3 \subsection{Related Approaches}
4
5 ``Chatty Things'' is not the only approach to implement communication in
6 embedded networks. This section gives a short overview of related protocols for
7 the Internet of Things and shows their advantages and disadvantages, which are
8 summarized in Table~\ref{tab:comparison}.
9
10 \begin{table}
11 \small\centering
12 \caption{Comparison of related approaches}
13 \label{tab:comparison}
14 \begin{tabular}{|l||l|l|l|l|}
15 \hline
16 Feature & Chatty Things & CoAP & MQTT & WS4D \\
17 \hline\hline
18 application gateways necessary & - & yes & yes & - \\ \hline
19 usable with standard clients & yes & - & - & (yes) \\ \hline
20 discovery support & yes & yes & - & yes\\ \hline
21 IPv6/6LoWPAN ready & yes & yes & ? & partial \\ \hline
22 asynchronous messages & yes & yes & & \\ \hline
23 protocol overhead & moderate & small & small & high \\ \hline
24 \end{tabular}
25 \end{table}
26
27 \paragraph{Constrained Application Protocol (CoAP)}
28
29 The Constrained Application Protocol~\cite{draft-ietf-core-coap-18} focuses on
30 machine-to-machine communication and originates from the IETF Constrained
31 Resources Working Group\footnote{\url{http://datatracker.ietf.org/wg/core/}},
32 but still has been only in draft status since 2010.\ It allows a mapping to
33 HTTP, and is therefore stateless, but it specifies a binary protocol, which
34 makes it necessary to deploy application-level gateways and special client
35 software to communicate with its environment. It relies on UDP, but emulates
36 congestion control, message confirmation and message IDs, since – in contrast to
37 HTTP – messages can be sent asynchronously. Discovery is also specified and done
38 over multicast, service discovery is then done over a well-known URI on the
39 host. Since it is a binary protocol and mostly self-contained, it has low
40 protocol overhead and parsing complexity.
41
42 \paragraph{MQ Telemetry Transport (MQTT)}
43
44 Specified by IBM as a binary protocol, the MQ Telemetry Transport~\cite{mqtt}
45 has been proposed as an OASIS standard for machine-to-machine communication. It
46 also relies on TCP/IP, and its fixed message header is only 2 bytes in size, but
47 can contain further variable headers. Since it is also only used in embedded
48 networks, application gateways and appropriate client software are necessary.
49 Its main feature is a publish-subscribe mechanism with topic names, discovery is
50 not specified.
51
52 \paragraph{Web Service for Devices (WS4D)}
53
54 As a different approach to avoid application-level gateways, WS4D has been
55 specified as a Devices Profile for Web Services~\cite{zeeb-moritz-ws4d}. Since
56 Web Services are wide-spread in the business world, this approach can probably
57 be used in existing infrastructures, and is also focused on multiple platforms
58 like embedded systems and servers. Web Services can be very flexible and
59 composable, and discovery is already specified, however, this also comes at a
60 cost: messages are enclosed in SOAP, which is enclosed in HTTP, which is
61 transported over TCP, which introduces a substantial overhead, especially with
62 SOAP being based on verbose XML. IPv6 support is only partially implemented.
63 For communication, standard APIs can be used.
64
65 \subsection{Conclusion}
66
67 With the XMPP
68 protocol, there is the need to implement at least an XML parser on each node,
69 which comes with protocol overhead and increased code size. However Klauck and
70 Kirsche show that with good optimization (in the code as well as in the
71 protocol), a complete stack can be implemented in 12 kBytes of ROM, which leaves
72 enough space for other applications to be built onto it. As compared to Web
73 Services, Chatty Things are probably not as flexible, but they have less
74 overhead, even when using XML, while MQTT and CoAP provide less flexibility for
75 future enhancement, but less protocol overhead and easier parsing.
76
77 With TCP, mDNS, DNS-SD and XMPP as foundation, the proposed architecture builds
78 on reliable and established standards, which allows it to reuse Chatty Things in
79 various contexts without the need for central infrastructure.
80
81 Nonetheless, a drawback is the virtual dependency from a centralized XMPP
82 server in order to use Temporary Subscription for Presence for topic filtering,
83 which is caused by the lack of support for Multi-User Chats in XEP-0174
84 (Serverless Messaging). If this gap can be closed, or a different way for topic
85 filtering in distributed networks is found, the server can be
86 eliminated and what remains is a highly distributed network without the need for
87 much central infrastructure, therefore eliminating most single points of failure
88 in the system.
89
90 It is always hard to trade flexibility and accessibility for efficiency. The
91 Chatty Things approach is probably not one of the most efficient, and not the
92 most flexible, but it has the big advantage that users can interact with their
93 things using standard chat clients, without the need for application gateways or
94 specialized software. In terms of efficiency, it chooses a compromise between
95 binary protocols and Web Services, latter which were originally developed for
96 servers with much less resource constraints as embedded systems. However, with
97 additional XEPs focusing on the Internet of Things, enough flexibility can be
98 achieved for this use case.
99
100 % vim: set ft=tex et ts=2 sw=2 :
This page took 0.080933 seconds and 5 git commands to generate.