--- /dev/null
+\section{Discussion}
+%\todo
+\pages{3}
+
+
+\subsection{Related Approaches}
+
+This section gives a short overview of related protocols for the Internet of
+Things and shows their advantages and disadvantages, which are summarized in
+Table~\ref{tab:comparison}.
+
+\begin{table}
+\small\centering
+\caption{Comparison of related approaches}
+\label{tab:comparison}
+\begin{tabular}{|l||l|l|l|l|}
+ \hline
+ Feature & Chatty Things & CoAP & MQTT & WS4D \\
+ \hline\hline
+ application gateways neccessary & - & yes & yes & - \\ \hline
+ usable with standard clients & yes & - & - & (yes) \\ \hline
+ discovery support & yes & yes & - & yes\\ \hline
+ IPv6/6LoWPAN ready & yes & yes & ? & partial \\ \hline
+ asynchronous messages & yes & yes & & \\ \hline
+ protocol overhead & moderate & small & small & high \\ \hline
+\end{tabular}
+\end{table}
+
+\paragraph{Constrained Application Protocol (CoAP)}
+
+The Constrained Application Protocol~\cite{draft-ietf-core-coap-18} focuses on
+machine-to-machine communication and originates from the IETF Constrained
+Resources Working Group, but still has been only in draft status since 2010.\ It
+allows a mapping to HTTP, and is therefore stateless, but it specifies a binary
+protocol, which makes it neccessary to deploy application-level gateways and
+special client software to communicate with its environment. It relies on UDP,
+but emulates congestion control, message confirmation and message IDs, since –
+in contrast to HTTP – messages can be sent asynchronously. Discovery is also
+specified and done over multicast, service discovery is then done over a
+well-known URI on the host. Since it is a binary protocol and mostly
+self-contained, it has low protocol overhead and parsing complexity.
+
+\paragraph{MQ Telemetry Transport (MQTT)}
+
+Specified by IBM as a binary protocol, the MQ Telemetry Transport~\cite{mqtt}
+has been proposed as an OASIS standard for machine-to-machine communication. It
+also relies on TCP/IP, and its fixed message header is only 2 bytes in size, but
+can contain further variable headers. Since it is also only used in embedded
+networks, application gateways and appropriate client software are necessary.
+Its main feature is a publish-subscribe mechanism with topic names, discovery is
+not specified.
+
+\paragraph{Web Service for Devices (WS4D)}
+
+As a different approach to avoid application-level gateways, WS4D has been
+specified as a Devices Profile for Web Services~\cite{zeeb-moritz-ws4d}. Since
+Web Services are wide-spread in the business world, this approach can probably
+be used in existing infrastructures, and is also focused on multiple platforms
+like embedded systems and servers. Web Services can be very flexible and
+composable, and discovery is already specified, however, this also comes at a
+cost: web services are enclosed in SOAP, which is enclosed in HTTP, which is
+transported over TCP, which introduces very much overhead, except with SOAP
+being based on verbose XML. IPv6 support is only partially implemented.
+For communication, standard APIs can be used.
+
+\subsection{Conclusion}
+
+ With the XMPP
+protocol, there is the need to implement at least an XML parser on each node,
+which comes with protocol overhead and increased code size. However Klauck and
+Kirsche show that with good optimization (in the code as well as in the
+procotol), a complete stack can be implemented in 12 kByte of ROM, which leaves
+enough space for other applications to build onto it. As compared to Web
+Services, Chatty Things are probably not as flexible, but they have less
+overhead, even when using XML, while MQTT and CoAP provide less flexibility for
+future enhancement, therefore less protocol overhead and easier parsing.
+
+With TCP, mDNS, DNS-SD and XMPP as foundation, the proposed architecture builds
+on reliable and established standards, which allows it to reuse Chatty Things in
+various contexts without the need for central infrastructure.
+
+Nonetheless, a drawback is the virtual dependency from a centralized XMPP
+server in order to use Temporary Subscription for Presence for topic filtering,
+which is caused by the lack of support for Multi-User Chats in XEP-0174
+(Serverless Messaging). If this gap can be closed, or a different way for topic
+filtering in distributed networks is found, the server can be
+eliminated and what remains is truly distributed network without the need for
+any central infrastructure, therefore eliminating every single point of failure
+in the system.
+
+It is always hard to trade flexibility and accessibility for efficiency. The
+Chatty Things approach is probably not one of the most efficient, and not the
+most flexible, but it has the big advantage that users can interact with their
+things using standard chat clients, without the need for application gateways or
+specialized software. In terms of efficiency, it chooses a common ground between
+binary protocols and Web Services, which were originally developed for servers
+with much less resource constraints as embedded systems.
+
+
+% vim: set ft=tex et ts=2 sw=2 :
projects / skm-ma-ws1314.git / blobdiff