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