X-Git-Url: https://git.rohieb.name/skm-ma-ws1314.git/blobdiff_plain/f505ad57144ab8d61bf5ba1eb4a967fbe73cb3b7..9c0186068ed8d750cbae9dae7740f312a7663fe8:/sec-discussion.tex?ds=sidebyside

diff --git a/sec-discussion.tex b/sec-discussion.tex
index e488f80..0f05d0c 100644
--- a/sec-discussion.tex
+++ b/sec-discussion.tex
@@ -1,6 +1,4 @@
 \section{Discussion}\label{sec:discussion}
-%\todo
-\pages{3}
 
 \subsection{Future Work}
 
@@ -11,10 +9,10 @@ status) are targeted to the Internet of Things.
 
 \paragraph{Concentrators (XEP-0326)~\cite{xep0326}}
 In contrast to sensor nodes which are focused on collecting data, concentrators
-can be used to control and serve as proxy for a subset of the network. The XEP
+can be used to serve as a proxy and control a subset of the network. The XEP
 defines messages to query a sensor node for data sources, and subscribing to
 them, while subscription is loosely modeled after the Publish-Subscribe
-mechanism (XEP-0060). It also specifies how clients can request data from or
+mechanism (XEP-0060). It also specifies how clients can request data or
 control certain nodes over a concentrator.
 
 This approach can be practical in large-scale sensor networks, where usually not
@@ -39,22 +37,21 @@ This XEP specifies a way of reading out values from a
 sensor node. It allows to specify multiple data sources (e.~g. temperature,
 humidity) as well as multiple types of data (e.~g., momentary values, historical
 values, peak values).
-As a simple use case, the client sends an \code{<iq>} stanza containing the request and a
+As a simple use case, the client sends an IQ stanza containing the request and a
 sequence number used to identify the request. The sensor node then rejects or
-accepts the request by returning a corresponding \code{<iq>} stanza. If it has
+accepts the request by returning a corresponding IQ stanza. If it has
 accepted the request, it reads out the requested data and returns it in a
-subsequent \code{<message>} stanza to the client.
+subsequent message stanza to the client.
 
-\paragraph{Control (XEP-0325)~\cite{xep0325}}
-In this document, a way of controlling sensor nodes is specified, which allows a
-client to get and set control values on the node over
-\code{<message>} or \code{<iq>} stanzas. As an example, in this way a sensor
-node can be instructed to return data in a different unit or range, or can be put
-into power-safe mode.
+\paragraph{Control (XEP-0325)~\cite{xep0325}} In this document, a way of
+controlling sensor nodes is specified, which allows a client to get and set
+control values on the node over message or IQ stanzas. As an example, in this
+way a sensor node could be instructed to return data in a different unit or
+range, or be put into power-safe mode.
 
 \paragraph{Provisioning (XEP-0324)~\cite{xep0324}}
 To protect the integrity of a sensor network and securing the data being
-collected, this document specifies a way of implementing access rights and user
+collected, this XEP specifies a way of implementing access rights and user
 privileges. Since a single sensor node is usually very restricted in user input and
 output, the approach is very simple and can be implemented e.~g. using a button
 and an LED for interaction, while presentation of data takes places on a
@@ -67,7 +64,7 @@ The node can e.~g. symbolize this request by blinking its LED and requesting a
 button press in the next 30 seconds. If the user presses the button, the node
 confirms the friendship to the server. The server then remembers this sensor
 node and generates a token which must be used in all further communication
-between the server and the sensor node or the communication is rejected.
+between the server and the sensor node, else communication is rejected.
 
 \paragraph{Efficient XML Interchange Format (EXI, XEP-0322)~\cite{xep0322}}
 Finally, EXI describes how XMPP stanzas sent between nodes can be compressed,
@@ -83,9 +80,9 @@ decrease message throughput and increase power consumption on embedded systems.
 
 \subsection{Related Approaches}
 
-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
+``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}
@@ -109,15 +106,16 @@ summarized in 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
-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 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)}
 
@@ -137,9 +135,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
-cost: web services are enclosed in SOAP, which is enclosed in HTTP, which is
-transported over TCP, which introduces very much overhead, especially 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}
@@ -163,16 +161,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
-eliminated and what remains is truly distributed network without the need for
-any central infrastructure, therefore eliminating most single points 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
-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.
+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 :
