redraw example XMPP stream with TikZ/PGF

[skm-ma-ws1314.git] / sec-discussion.tex

diff --git a/sec-discussion.tex b/sec-discussion.tex
index c882773..0c3838d 100644 (file)
--- a/sec-discussion.tex
+++ b/sec-discussion.tex
@@ -1,13 +1,11 @@
-\section{Discussion}
-%\todo
-\pages{3}
-
+\section{Discussion}\label{sec:discussion}

 
 \subsection{Related Approaches}
 
 
 \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}.
+``Chatty Things'' is not the only approach to implement communication in
+embedded networks. 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
 
 \begin{table}
 \small\centering


@@ -17,7 +15,7 @@ Table~\ref{tab:comparison}.
   \hline
   Feature & Chatty Things & CoAP & MQTT & WS4D \\
   \hline\hline
   \hline
   Feature & Chatty Things & CoAP & MQTT & WS4D \\
   \hline\hline

-  application gateways neccessary & - & yes & yes & - \\ \hline
+  application gateways necessary & - & yes & yes & - \\ \hline

   usable with standard clients & yes & - & - & (yes) \\ \hline
   discovery support & yes & yes & - & yes\\ \hline
   IPv6/6LoWPAN ready & yes & yes & ? & partial \\ \hline
   usable with standard clients & yes & - & - & (yes) \\ \hline
   discovery support & yes & yes & - & yes\\ \hline
   IPv6/6LoWPAN ready & yes & yes & ? & partial \\ \hline


@@ -30,15 +28,16 @@ Table~\ref{tab:comparison}.
 
 The Constrained Application Protocol~\cite{draft-ietf-core-coap-18} focuses on
 machine-to-machine communication and originates from the IETF Constrained
 
 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.
+Resources Working Group\footnote{\url{http://datatracker.ietf.org/wg/core/}},
+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 necessary 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)}
 
 
 \paragraph{MQ Telemetry Transport (MQTT)}
 


@@ -58,9 +57,9 @@ 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
 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.
+cost: messages are enclosed in SOAP, which is enclosed in HTTP, which is
+transported over TCP, which introduces a substantial overhead, especially with
+SOAP being based on verbose XML. IPv6 support is only partially implemented.

 For communication, standard APIs can be used.
 
 \subsection{Conclusion}
 For communication, standard APIs can be used.
 
 \subsection{Conclusion}


@@ -69,11 +68,11 @@ For communication, standard APIs can be used.
 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
 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
+protocol), a complete stack can be implemented in 12 kBytes of ROM, which leaves
+enough space for other applications to be built 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
 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.
+future enhancement, but 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
 
 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


@@ -84,35 +83,18 @@ 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
 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
+eliminated and what remains is a highly distributed network without the need for
+much central infrastructure, therefore eliminating most single points 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
 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.
-
-Nonetheless, there are a few additional XEPs which can be implemented to further
-increase the effictivity of Chatty Things. XEP-0322 (Efficient XML Interchange
-Format)~\cite{xep0322} describes how XMPP stanzas sent between a server and a
-client can be compressed, therefore effectively reducing the overhead introduced
-by XML. A client and a server can then negotiate a compressed stream inside
-their existing XMPP stream and exchange \code{<compress>} stanzas which contain
-the payload.
-
-The documents XEP-0324 through XEP-0326 contain specifications targeted
-especially to the Internet of Things:
-
-\todo{additional XEPs, example XML stream with sensor data}
-
-\begin{itemize}
- \item asdf
- \item asdfasdf
- \item lkjlkj
-\end{itemize}
+specialized software. In terms of efficiency, it chooses a compromise between
+binary protocols and Web Services, latter which were originally developed for
+servers with much less resource constraints as embedded systems. However, with
+additional XEPs focusing on the Internet of Things, enough flexibility can be
+achieved for this use case.

 
 % vim: set ft=tex et ts=2 sw=2 :
 
 % vim: set ft=tex et ts=2 sw=2 :