sync: discussion

diff --git a/main.tex b/main.tex
index 51d61f4..38eaf82 100644 (file)
--- a/main.tex
+++ b/main.tex
@@ -26,15 +26,18 @@ Masses with XMPP}
 \section{Introduction}
 \todo
 \pages{0-1}
 \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}
 
 %% 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}
 \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}
 
 \bibliographystyle{plain}
 \bibliography{biblio}

diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex
index fe69f94..f7ef5a8 100644 (file)
--- 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:
 
 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
 \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 (file)
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 (file)
--- 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
   \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}
 
   \label{fig:dnssd}
 \end{figure}