From d86e1187722a1fc2aeeb59a03e79fb364b4814ba Mon Sep 17 00:00:00 2001 From: Roland Hieber Date: Sat, 14 Dec 2013 09:36:45 +0100 Subject: [PATCH] sync: discussion --- main.tex | 64 +++++--------------------- sec-chatty-things.tex | 2 +- sec-discussion.tex | 100 +++++++++++++++++++++++++++++++++++++++++ sec-dns-extensions.tex | 2 +- 4 files changed, 114 insertions(+), 54 deletions(-) create mode 100644 sec-discussion.tex diff --git a/main.tex b/main.tex index 51d61f4..38eaf82 100644 --- a/main.tex +++ b/main.tex @@ -26,15 +26,18 @@ Masses with XMPP} \section{Introduction} \todo \pages{0-1} -short overview, not too long: what do we want, what are we -going to do +short overview, not too long: what do we want, what are we going to do? -basically: how do we talk to our smart home? -\paragraph{Human-to-Machine Communication:} especiall in the Internet of Things, - Chatty Things need to be accessible for the user and should be easy to talk - to. -\paragraph{Interoperability} integration into already existing -infrastructure. +how do we talk to our smart home? + +what are the challenges? (interoperability, H2M interface, self-configuration, +information filtering to prevent information overflow) + +%\paragraph{Human-to-Machine Communication:} especiall in the Internet of Things, + %Chatty Things need to be accessible for the user and should be easy to talk + %to. +%\paragraph{Interoperability} integration into already existing +%infrastructure. %% Prerequisites \section{Prerequisites} @@ -47,50 +50,7 @@ overview to the techniques used in the paper by Klauk and Kirsche \input{sec-dns-extensions.tex} \input{sec-xmpp.tex} \input{sec-chatty-things.tex} - -\section{Related Approaches} -\todo -\pages{3} -Middleware, Application protocol gateways: -\begin{itemize} - \item Constrained Application Protocol \cite{draft-ietf-core-coap-18} - \begin{itemize} - \item machine-to-machine - \item everything-built-in - \item discovery over multicast, service discovery over /.well-known - entry-point - \item maps to HTTP => stateless => relies on application gateway - \item low protocol overhead and parsing complexity (binary messages) - \item only draft status - \item UDP with Ack and IDs instead of TCP... (limited state machine) - \item proxies - \item asynchronous messages - \end{itemize} - \item MQ Telemetry Transport \cite{mqtt} - \begin{itemize} - \item TCP/IP - \item small overhead: 2 byte header + variable header length - \item publish-subscribe with topic names - \item binary protocol => application-level gateway - \item discovery? - \end{itemize} - \item Devices Profile for Web Services \cite{zeeb-moritz-ws4d} - \begin{itemize} - \item TCP/IP -> HTTP -> SOAP -> Web Services. Overhead! - \item but very extendable and composable - \item discovery as a service - \item focused on multiple platforms, deeply embedded and servers - \item IPv6 partly experimental - \item ROM usage of uDPWS: 45 kByte - \end{itemize} - -\end{itemize} - -\section{Discussion} -\todo -comparison of mentioned approaches - -\pages{1-2} +\input{sec-discussion.tex} \bibliographystyle{plain} \bibliography{biblio} diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex index fe69f94..f7ef5a8 100644 --- a/sec-chatty-things.tex +++ b/sec-chatty-things.tex @@ -32,7 +32,7 @@ Furthermore, Klauck and Kirsche implemented new features for uXMPP, which were realized as separate modules to allow enabling and disabling them at runtime, thus further reducing the memory footprint of a running system: -\todo[minimize space between list item] +\todo[minimize space between list items] \begin{itemize} \item support for IPv6 \item support for Multi-User Chats (XEP-0045), which are used for information diff --git a/sec-discussion.tex b/sec-discussion.tex new file mode 100644 index 0000000..1877d68 --- /dev/null +++ b/sec-discussion.tex @@ -0,0 +1,100 @@ +\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 : diff --git a/sec-dns-extensions.tex b/sec-dns-extensions.tex index 7ef413c..f54df18 100644 --- a/sec-dns-extensions.tex +++ b/sec-dns-extensions.tex @@ -51,7 +51,7 @@ and \term{Service Instance Resolution}. \centering \includegraphics[width=0.9\textwidth]{fig-dnssd-mock.jpg} \caption{DNS-SD: Service Instance Enumeration and Resolution - \todo[XMPP is a bad example here, use IPP]} + \todo[XMPP is a probably not the best example here, use IPP instead]} \label{fig:dnssd} \end{figure} -- 2.20.1