polishing

diff --git a/main.tex b/main.tex
index d187088..cd97214 100644 (file)
--- a/main.tex
+++ b/main.tex
@@ -28,7 +28,6 @@ Masses with XMPP}
 \maketitle
 
 \input{sec-intro.tex}
 \maketitle
 
 \input{sec-intro.tex}

-

 %% Prerequisites
 \section{Prerequisites}\label{sec:prereq}
 
 %% Prerequisites
 \section{Prerequisites}\label{sec:prereq}
 

diff --git a/sec-address-allocation.tex b/sec-address-allocation.tex
index d2d0625..ba09a10 100644 (file)
--- a/sec-address-allocation.tex
+++ b/sec-address-allocation.tex
@@ -5,14 +5,14 @@ IP layer, a device needs to configure one of its network interfaces with an IP
 address that can be reached from the network that the device wants to connect
 to. Letting the user choose and configure IP addresses manually is a cumbersome
 when it comes to several devices. Deploying a central server for assigning IP
 address that can be reached from the network that the device wants to connect
 to. Letting the user choose and configure IP addresses manually is a cumbersome
 when it comes to several devices. Deploying a central server for assigning IP

-addresses automatically from a pre-configured address pool is possible (e.~g.
-using the DHCP protocol~\cite{rfc2131}), however, there is also the alternative
+addresses automatically from a pre-configured address pool is possible (e.~g. by
+using DHCP~\cite{rfc2131}), however, there is also the alternative

 to use a distributed protocol which enables the devices on a network to choose
 to use a distributed protocol which enables the devices on a network to choose

-addresses in accordance with each other so no IP address is used twice.
+addresses in accordance with each other, so no IP address is used twice.

 
 In respect to the Internet of Things, this decentralized approach has the
 
 In respect to the Internet of Things, this decentralized approach has the

-advantage that devices can easily be used in different scenarios, even when
-central deployment does not exist, and it also allows them to change their
+advantage that devices can easily be used in different desployments, even where
+central infrastructures do not exist, and it also allows them to change their

 addresses dynamically in order to react to changes in the network.
 
 There are two major protocols which are used for dynamic configuration of IP
 addresses dynamically in order to react to changes in the network.
 
 There are two major protocols which are used for dynamic configuration of IP


@@ -42,18 +42,17 @@ Stateless Address Auto\-configuration} use an IPv6 address from the subnet
 which can be random, or based on the interface's MAC address. Most likely, this
 interface identifier is unique in the network, so a unique IPv6 address is
 obtained by combining the subnet prefix and the interface identifier.
 which can be random, or based on the interface's MAC address. Most likely, this
 interface identifier is unique in the network, so a unique IPv6 address is
 obtained by combining the subnet prefix and the interface identifier.

-Nonetheless, to ensure that no other device use the generated IPv6 address, the
+Nonetheless, to ensure that no other device uses the generated IPv6 address, the

 device performs \term{Duplicate Address Detection} on the network by
 device performs \term{Duplicate Address Detection} on the network by

-broadcasting
-its generated address with \term{Neighbor Advertisement} messages and listening
-for \term{Neighbor Solicitation} messages. If such a message is received from
-another hosts, the generated address cannot be used by the device and must be
-discarded, and the address generation process is repeated until a unique
-address has been found.
+broadcasting its generated address with \term{Neighbor Advertisement} messages
+and listening for \term{Neighbor Solicitation} messages. If such a message is
+received from another hosts, the generated address cannot be used by the device
+and must be discarded, and the address generation process is repeated until a
+unique address has been found.

 
 In contrast to IPv4 Link-Local Addressing, IPv6 Stateless Address
 
 In contrast to IPv4 Link-Local Addressing, IPv6 Stateless Address

-Autoconfiguration can also be used with a central server. In this case, a
-central server broadcasts \term{Router Solicitation} messages on the network
+Autoconfiguration can also be used with a central server. In this case, the
+server broadcasts \term{Router Solicitation} messages on the network

 which contain a global network prefix. The hosts on the network can then use
 that prefix instead to configure a global IPv6 address.
 
 which contain a global network prefix. The hosts on the network can then use
 that prefix instead to configure a global IPv6 address.
 

diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex
index 13407c0..da27fbe 100644 (file)
--- a/sec-chatty-things.tex
+++ b/sec-chatty-things.tex
@@ -4,14 +4,13 @@ After the underlying techniques have been explained, we can now have a look at
 the system architecture which Klauck and
 Kirsche~\cite{Klauck:2012:BCC:2352852.2352881} use to build Chatty Things.
 
 the system architecture which Klauck and
 Kirsche~\cite{Klauck:2012:BCC:2352852.2352881} use to build Chatty Things.
 

-\pages{3}

 \subsection{Service Provisioning Sublayer}
 
 Considering the application in deeply embedded systems and the special needs of
 the Internet of Things on the one hand, the protocol stack needs to fulfil
 certain technical requirements.
 
 \subsection{Service Provisioning Sublayer}
 
 Considering the application in deeply embedded systems and the special needs of
 the Internet of Things on the one hand, the protocol stack needs to fulfil
 certain technical requirements.
 

-First, memory, computing resources and bandwith on embedded systems are limited,
+First, memory, computing resources and bandwidth on embedded systems are limited,

 which demands for a lightweight protocol stack without too much overhead and
 predictable memory consumption, while also retaining enough flexibility for
 future development. The authors therefore provide only the most essential
 which demands for a lightweight protocol stack without too much overhead and
 predictable memory consumption, while also retaining enough flexibility for
 future development. The authors therefore provide only the most essential


@@ -32,14 +31,13 @@ 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 items}

 \begin{itemize}
   \item support for IPv6
   \item support for Multi-User Chats (XEP-0045), which are used for information
     filtering
   \item support for SASL ANONYMOUS login for XMPP servers \cite{xep0175}
   \item a new publish-subscribe mechanism called Temporary Subscription for
 \begin{itemize}
   \item support for IPv6
   \item support for Multi-User Chats (XEP-0045), which are used for information
     filtering
   \item support for SASL ANONYMOUS login for XMPP servers \cite{xep0175}
   \item a new publish-subscribe mechanism called Temporary Subscription for

-    Presence (see \ref{sec:tsp})
+    Presence (see Section~\ref{sec:tsp})

   \item XMPP Serverless Messaging (XEP-0174), using \term{uBonjour} as
     underlying mDNS/DNS-SD implementation for Contiki.
 \end{itemize}
   \item XMPP Serverless Messaging (XEP-0174), using \term{uBonjour} as
     underlying mDNS/DNS-SD implementation for Contiki.
 \end{itemize}


@@ -57,13 +55,13 @@ detected over uBonjour, it is used instead with the ANONYMOUS login method, and
 the XEP-0174 module is disabled. The ANONYMOUS login method is chosen since TLS
 encryption is not yet implemented, and with this method, the server assigns a
 random JID to the client, which does not need to exist on the server. However, a
 the XEP-0174 module is disabled. The ANONYMOUS login method is chosen since TLS
 encryption is not yet implemented, and with this method, the server assigns a
 random JID to the client, which does not need to exist on the server. However, a

-server must exist and must be configured to use this login method in order to
-use this method.
+server must exist and must be configured to supply this login method in order
+for this approach to work.

 
 With a server, information filtering is achieved by creating topic-based
 Multi-User Chats where multiple devices can be grouped. A user can then simply
 join the chat with a standard XMPP client on her machine and interact with all
 
 With a server, information filtering is achieved by creating topic-based
 Multi-User Chats where multiple devices can be grouped. A user can then simply
 join the chat with a standard XMPP client on her machine and interact with all

-devices of a topic, or she can also interact with them directly.
+devices of a topic, or she can also interact with single devices directly.

 
 In scenarios without an XMPP server, the XEP-0174 module is activated and
 devices talk directly with the user or with other devices. This method has the
 
 In scenarios without an XMPP server, the XEP-0174 module is activated and
 devices talk directly with the user or with other devices. This method has the


@@ -93,14 +91,16 @@ over XMPP Serverless Messaging.
 Bootstrapping a Chatty Thing therefore incorporates three steps:
 
 \begin{enumerate}
 Bootstrapping a Chatty Thing therefore incorporates three steps:
 
 \begin{enumerate}

-  \item Activate uBonjour and try to discover an XMPP server
+  \item Activate uBonjour and try to discover an XMPP server.

   \item If a server is found, connect to it using ANONYMOUS login, join
     topic-based Multi-User Chats, deactivate the uBonjour client
   \item If a server is found, connect to it using ANONYMOUS login, join
     topic-based Multi-User Chats, deactivate the uBonjour client

-    \term(Infrastructure mode).
-  \item If no server is found, activate the XEP-0174 client \term{Ad-hoc mode}.
+    \term{(Infrastructure mode).}
+  \item If no server is found, activate the XEP-0174 client \term{(Ad-hoc
+    mode)}.

 \end{enumerate}
 
 \end{enumerate}
 

-During runtime, a device can then react to changes in network infrastructure:
+During runtime, a device can then react to changes in network infrastructure by
+changing from one mode to the other:

 
 \begin{itemize}
   \item In Infrastructure mode: when connection to the server is lost, enable
 
 \begin{itemize}
   \item In Infrastructure mode: when connection to the server is lost, enable


@@ -111,8 +111,6 @@ During runtime, a device can then react to changes in network infrastructure:
     Messaging and uBonjour and join topic-based Multi-User Chats.
 \end{itemize}
 
     Messaging and uBonjour and join topic-based Multi-User Chats.
 \end{itemize}
 

-\todo{short conclusion?}
-

 \subsection{Temporary Subscription for Presence}\label{sec:tsp}
 
 To further reduce the message overhead and allow more fine-grained control over
 \subsection{Temporary Subscription for Presence}\label{sec:tsp}
 
 To further reduce the message overhead and allow more fine-grained control over


@@ -125,8 +123,8 @@ subscribe to presence information of another client in order to receive it,
 which requires further communication between the clients. Since the network can
 change rapidly, and clients can frequently join and leave the network,
 subscriptions would often be outdated and must be renewed, leading to overhead
 which requires further communication between the clients. Since the network can
 change rapidly, and clients can frequently join and leave the network,
 subscriptions would often be outdated and must be renewed, leading to overhead

-of subscriptions and unsubscription packets, which would inhibit the flow of the
-actual information.
+of subscriptions and unsubscription messages, which would inhibit the flow of
+the actual information.

 
 To solve this problem, a dynamic, topic-based roster is implemented on top of
 Multi-User Chats (XEP-0045). Every topic corresponds with a chat room, and nodes
 
 To solve this problem, a dynamic, topic-based roster is implemented on top of
 Multi-User Chats (XEP-0045). Every topic corresponds with a chat room, and nodes

diff --git a/sec-discussion.tex b/sec-discussion.tex
index e488f80..0f05d0c 100644 (file)
--- a/sec-discussion.tex
+++ b/sec-discussion.tex
@@ -1,6 +1,4 @@
 \section{Discussion}\label{sec:discussion}
 \section{Discussion}\label{sec:discussion}

-%\todo
-\pages{3}

 
 \subsection{Future Work}
 
 
 \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
 
 \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
 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
 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).
 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
 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
 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
 
 \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
 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
 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,
 
 \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}
 
 
 \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}
 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
 
 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)}
 
 
 \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
 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}
 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
 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
 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 :
 
 % vim: set ft=tex et ts=2 sw=2 :

diff --git a/sec-dns-extensions.tex b/sec-dns-extensions.tex
index d3ec16e..dae9770 100644 (file)
--- a/sec-dns-extensions.tex
+++ b/sec-dns-extensions.tex
@@ -5,12 +5,14 @@ authoritative DNS server, and there is usually no easy way to discover services.
 The first problem is addressed with \term{Multicast DNS}, and since DNS is
 basically a key-value store, it can also be used for service discovery, which is
 achieved using \term{DNS-Based Service Discovery}. Both techniques were first
 The first problem is addressed with \term{Multicast DNS}, and since DNS is
 basically a key-value store, it can also be used for service discovery, which is
 achieved using \term{DNS-Based Service Discovery}. Both techniques were first

-developed by Apple as part of the \term{Bonjour} project, and are now maintained
-by the IETF Zeroconf working group.
+developed by Apple as part of the \term{Bonjour}
+project\footnote{\url{https://developer.apple.com/bonjour/}}, and are now
+maintained by the IETF Zeroconf working
+group\footnote{\url{http://zeroconf.org}}.

 
 \subsubsection{Multicast DNS}
 
 
 \subsubsection{Multicast DNS}
 

-\term{Multicast DNS}~\cite{rfc6762} (mDNS) describes an extension to the Domain
+\term{Multicast DNS} (mDNS)~\cite{rfc6762} describes an extension to the Domain

 Name System that allows DNS resource records to be distributed on multiple hosts
 in a network, therefore avoiding central authorities and enabling every host to
 publish its own entries. For that purpose, a special domain, usually
 Name System that allows DNS resource records to be distributed on multiple hosts
 in a network, therefore avoiding central authorities and enabling every host to
 publish its own entries. For that purpose, a special domain, usually


@@ -33,51 +35,42 @@ than one host (e.~g., SRV records). The hosts matching those resources then do
 not generate a response, thus reducing the messages in the network and saving
 bandwidth, which is usually a scarce resource in wireless networks.
 
 not generate a response, thus reducing the messages in the network and saving
 bandwidth, which is usually a scarce resource in wireless networks.
 

+\enlargethispage{2\baselineskip}

 Finally, hosts may also send unsolicited responses. This can be used to notify
 the network of new services available on a host.
 
 Finally, hosts may also send unsolicited responses. This can be used to notify
 the network of new services available on a host.
 

-\pages{1}
-

 \subsubsection{DNS-Based Service Discovery}\label{sec:dnssd}
 
 As another recent extension for the Domain Name System, \term{DNS-Based Service
 Discovery (DNS-SD)}~\cite{rfc6763} uses DNS records of types
 \subsubsection{DNS-Based Service Discovery}\label{sec:dnssd}
 
 As another recent extension for the Domain Name System, \term{DNS-Based Service
 Discovery (DNS-SD)}~\cite{rfc6763} uses DNS records of types

-\code{SRV}~\cite{rfc2782} and \code{PTR} in a way that allows hosts to browse
-for services in a domain. As an example, Figure~\ref{fig:dnssd} shows the
-process of browsing for all XMPP clients in the domain \code{example.org}.
-This is a two-step process, consisting of \term{Service Instance Enumeration}
-and \term{Service Instance Resolution}.
-
-\todo{XMPP is a probably not the best example here, use IPP instead}
-\begin{figure}[top]
-  \centering
-  \includegraphics[width=0.9\textwidth]{fig-dnssd-mock.jpg}
-  \caption{DNS-SD: Service Instance Enumeration and Resolution}
-  \label{fig:dnssd}
-\end{figure}
+SRV~\cite{rfc2782} and PTR in a way that allows hosts to browse
+for services in a domain. This is a two-step process, consisting of
+\term{Service Instance Enumeration} and \term{Service Instance Resolution}.

 
 

-\paragraph{Service Instance Enumeration} At first, to enumerate the available
+%\todo{XMPP is a probably not the best example here, use IPP instead}
+%\begin{subfigure} \end{subfigure} \begin{figure}[top] \centering
+%\includegraphics[width=0.9\textwidth]{fig-dnssd-mock.jpg} \caption{DNS-SD:
+%Service Instance Enumeration and Resolution} \label{fig:dnssd} \end{figure}
+\paragraph{1. Service Instance Enumeration} At first, to enumerate the available

 services in a domain for a given protocol, a DNS-SD-enabled client queries
 services in a domain for a given protocol, a DNS-SD-enabled client queries

-resources of type \code{PTR} of the form \code{\_service.\_proto.domain}. The
-result of this query is then a list of \term{instance names} of the form
-\code{name.\_service.\_proto.domain} which provide the specified service. For
-example, in Figure~\ref{fig:dnssd}, by querying for
-\code{\_ipp.\_tcp.\_example.org}, all printers supporting the IPP protocol in the
-domain \code{example.org} are enumerated, and as a result, the instance names of
-three hosts are returned.
+PTR resources of the form \code{\_service.\_proto.domain}. The result of
+this query is then a list of \term{instance names} of the form
+\code{name.\_service.\_proto.domain} which point to the hosts providing the
+service. For example, by querying for \code{\_ipp.\_tcp.\_example.org}, the
+instance names for all printers supporting the IPP protocol in the domain
+\code{example.org} are returned.

 
 

-\paragraph{Service Instance Resolution} As a second step, the returned instance
-names are resolved as \code{SRV} records to retrieve the actual host names and
-port numbers of a service. In the example, resolution of one instance name shows
+\paragraph{2. Service Instance Resolution} As a second step, the returned instance
+names are resolved as SRV records to retrieve the actual host names and
+port numbers of a service. For example, resolution of one instance name shows

 that an IPP server is running at host \code{gutenberg.example.org} on port 5222.
 that an IPP server is running at host \code{gutenberg.example.org} on port 5222.

-Additionally, an optional \code{TXT} record with the same instance name can
-contain further information about the service (e.~g., information about the
+Additionally, an optional TXT record with the same instance name can
+contain further information about the service (e.~g. information about the

 supported paper sizes).
 
 supported paper sizes).
 

-Through the usage of \code{SRV} records, it is easily possible for a service to
+Through the usage of SRV records, it is easily possible for a service to

 inform clients about non-standard port numbers, and especially in connection
 inform clients about non-standard port numbers, and especially in connection

-with Multicast DNS makes it easy to deploy decentralized systems for the
-Internet of Things~\cite{Klauck:2012:BCC:2352852.2352881}.
+with Multicast DNS, this makes it easy to deploy decentralized systems for the
+Internet of Things. \cite{Klauck:2012:BCC:2352852.2352881}

 
 

-\pages{1}

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

diff --git a/sec-intro.tex b/sec-intro.tex
index 6a385d9..b93bd66 100644 (file)
--- a/sec-intro.tex
+++ b/sec-intro.tex
@@ -1,7 +1,5 @@
 %% Introduction
 \section{Introduction}
 %% Introduction
 \section{Introduction}

-\todo{asdf}
-\pages{0-1}

 
 Following the vision of the ``Internet of Things'', the amount of wireless
 devices is steadily increasing, which not only improves our standard of living
 
 Following the vision of the ``Internet of Things'', the amount of wireless
 devices is steadily increasing, which not only improves our standard of living

diff --git a/sec-xmpp.tex b/sec-xmpp.tex
index 41a9ca4..9f1749a 100644 (file)
--- a/sec-xmpp.tex
+++ b/sec-xmpp.tex
@@ -1,22 +1,23 @@
 \subsection{XMPP}
 \subsection{XMPP}

-\pages{3-4}

 
 The \term{Extensible Messaging and Presence Protocol (XMPP)} is a distributed,
 XML-based protocol for real-time communication. Its core functionalities are
 
 The \term{Extensible Messaging and Presence Protocol (XMPP)} is a distributed,
 XML-based protocol for real-time communication. Its core functionalities are

-specified in RFCs~6120~\cite{rfc6120} and RFC~6122~\cite{rfc6121}, while protocol
+specified in RFC~6120~\cite{rfc6120} and RFC~6122~\cite{rfc6121}, while protocol

 extensions are usually defined by the XMPP community in \term{XMPP Extension
 Proposals (XEPs)}.
 
 \subsubsection{Addressing}
 extensions are usually defined by the XMPP community in \term{XMPP Extension
 Proposals (XEPs)}.
 
 \subsubsection{Addressing}

+\enlargethispage{2\baselineskip}

 
 Every user account in XMPP is addressed by a globally unique identifier, called
 the \term{Jabber ID (JID)}~\cite{rfc6122}. It has the form
 
 Every user account in XMPP is addressed by a globally unique identifier, called
 the \term{Jabber ID (JID)}~\cite{rfc6122}. It has the form

-\code{localpart@domainpart/resource}, where \code{domainpart} is the DNS name of
-an XMPP server, and \code{localpart} is the name of a user account on that
-server. Since a user can be logged in from multiple clients, the \code{resource}
-part is a string chosen by the user to distinguish those clients. Only the part
-\code{localpart@domainpart} (the \term{bare JID}) is needed to identify a user,
-the resource is only needed for routing between client and server.
+\code{localpart@domain/resource}, where \code{domain} is the DNS name of an XMPP
+server, and \code{localpart} is the name of a user account on that server. Since
+a user can be logged in from multiple clients at the same time, the
+\code{resource} part is a string chosen by the user to distinguish those
+clients. Only the part \code{localpart@domain} (the \term{bare JID}) is
+needed to identify a user, the resource is only needed for routing between
+client and server.

 
 \subsubsection{Architecture}
 \begin{wrapfigure}{r}{0.5\textwidth}
 
 \subsubsection{Architecture}
 \begin{wrapfigure}{r}{0.5\textwidth}


@@ -46,10 +47,10 @@ the resource is only needed for routing between client and server.
 The original architecture underlying XMPP strongly leans on the established
 design of Internet Mail, and an example is depicted in Fig.~\ref{fig:xmpparch}.
 The distributed network is formed by \term{XMPP servers} on one hand, which make
 The original architecture underlying XMPP strongly leans on the established
 design of Internet Mail, and an example is depicted in Fig.~\ref{fig:xmpparch}.
 The distributed network is formed by \term{XMPP servers} on one hand, which make

-up the always-on backbone of the network used for message routing, and manage
-user accounts and statuses. On the other hand, \term{XMPP clients} represent a
-single logged-in user and make up the interface for communication with other
-users.
+up the always-on backbone of the network used for message routing, and which
+manage user accounts and statuses. On the other hand, \term{XMPP clients}
+represent a single logged-in user and make up the interface for communication
+with other users.

 
 Every client communicates only with the server that manages the respective user
 account which is configured in the client, as given in the user's JID. The
 
 Every client communicates only with the server that manages the respective user
 account which is configured in the client, as given in the user's JID. The


@@ -78,16 +79,18 @@ followed by an opening \code{<stream>} tag. The server then responds also with
 an opening \code{<stream>} tag. The client then performs SASL authentication and
 binds its stream to a resource for proper addressing. If this process succeeded,
 both client and server can send an unlimited number of stanzas, until the
 an opening \code{<stream>} tag. The client then performs SASL authentication and
 binds its stream to a resource for proper addressing. If this process succeeded,
 both client and server can send an unlimited number of stanzas, until the

-connection is closed by one side by sending an closing \code{</stream>} tag. The
+connection is closed by one side by sending a closing \code{</stream>} tag. The

 other side then has the chance to send all outstanding stanzas and then likewise
 closes its stream. If both streams are closed, the underlying TCP connection is
 terminated.
 
 other side then has the chance to send all outstanding stanzas and then likewise
 closes its stream. If both streams are closed, the underlying TCP connection is
 terminated.
 

+%\todo{see section... for example stream}
+

 \subsubsection{Publish/Subscribe and Presence}
 
 Typically, a user wants to chat with a more or less fixed set of other users,
 whose JIDs she needs to know, so she needs some kind of ``address book'' that
 \subsubsection{Publish/Subscribe and Presence}
 
 Typically, a user wants to chat with a more or less fixed set of other users,
 whose JIDs she needs to know, so she needs some kind of ``address book'' that

-remembers the JIDs for her. In XMPP, this is address book is called
+remembers the JIDs for her. In XMPP, this address book is called

 \term{roster}, and it also shows the users' willingness to chat (``presence'').
 In order to see their chat status (which can be  one of ``online'', ``offline'',
 and several ``away'' or ``do not disturb'' states), a user needs to subscribe to
 \term{roster}, and it also shows the users' willingness to chat (``presence'').
 In order to see their chat status (which can be  one of ``online'', ``offline'',
 and several ``away'' or ``do not disturb'' states), a user needs to subscribe to


@@ -109,27 +112,52 @@ All communication takes place between the client and the server over \code{<iq>}
 
 Besides one-to-one messaging, XMPP also allows users to create multi-user chat
 rooms, which is specified in XEP-0045~\cite{xep0045}. Each chat room is given a
 
 Besides one-to-one messaging, XMPP also allows users to create multi-user chat
 rooms, which is specified in XEP-0045~\cite{xep0045}. Each chat room is given a

-unique JID to which the users send their messages to. Each incoming message is
-then dispatched to all users which have joined the room.
+unique JID on the server managing the room to which the users send their
+messages to. Each incoming message is then dispatched to all users which have
+joined the room.

 
 To join a room, the user sends a \code{<presence>} stanza to the room JID, where
 the resource part of the room JID specifies the desired nick name.
 
 \subsubsection{XMPP Serverless Messaging}\label{sec:xsm}
 
 To join a room, the user sends a \code{<presence>} stanza to the room JID, where
 the resource part of the room JID specifies the desired nick name.
 
 \subsubsection{XMPP Serverless Messaging}\label{sec:xsm}

-\pages{1}

 
 To overcome the need for a central server and authentication, XMPP Serverless
 Messaging~\cite{xep0174} allows XMPP clients on a network to build a
 peer-to-peer mesh network and chat directly with each other. This feature was
 
 To overcome the need for a central server and authentication, XMPP Serverless
 Messaging~\cite{xep0174} allows XMPP clients on a network to build a
 peer-to-peer mesh network and chat directly with each other. This feature was

-first introduced by Apple as part of their \term{Bonjour}\footnote{see
-\url{https://developer.apple.com/bonjour/}} project, and nowadays it is also
-available in many other XMPP clients.
-
-With XMPP Serverless Messaging, XMPP clients simply open a port on the host, and
-then rely on mDNS and DNS-SD (see Section~\ref{sec:dns})
-to publish instance names in the domain \code{\_presence.\_tcp.local}. For
-example, if Juliet uses her machine (named \code{capulet}) with serverless
-messaging, her client would publish the following four mDNS records:
+first introduced by Apple as part of their \term{Bonjour} project, and nowadays
+it is also available in many other XMPP clients.
+
+%\begin{wrapfigure}{R}{0.4\textwidth}
+  %\tikzstyle{iconlabel}=[text width=2cm, align=center, font=\footnotesize]
+  %\tikzstyle{label}=[font=\footnotesize]
+  %\begin{tikzpicture}[node distance=0pt,scale=1.2,>=stealth,thick]
+    %\def\nodelist{
+      %juliet/{(-1,-1)}/\code{juliet@\ balcony.local}/below/computer,
+      %tybalt/{(-1,1)}/\code{tybalt@\ montague.local}/above/computer,
+      %mercutio/{(1,1)}/\code{mercutio@\ capulet.local}/above/computer,
+      %romeo/{(1,-1)}/\code{romeo@\ romeo.local}/below/computer%
+    %}
+    %\foreach \name/\pos/\text/\tpos/\icon in \nodelist {
+      %\node (\name) at \pos { \includegraphics[width=1cm]{icon-\icon.pdf} };
+      %\node[\tpos=of \name,iconlabel] (\name text) { \text };
+    %}
+    %\draw[<->,dashed] (juliet) -- (tybalt);
+    %\draw[<->,dashed] (juliet) -- (romeo);
+    %\draw[<->,dashed] (juliet) -- (mercutio);
+    %\draw[<->,dashed] (romeo) -- (mercutio);
+    %\draw[<->,dashed] (romeo) -- (tybalt);
+    %\draw[<->,dashed] (mercutio) -- (tybalt);
+  %\end{tikzpicture}
+  %\centering
+  %\caption{XMPP architecture with Serverless Messaging}
+  %\label{fig:xmpparch2}
+%\end{wrapfigure}
+
+With XMPP Serverless Messaging, XMPP clients simply open a port on their host,
+and then rely on mDNS and DNS-SD (see Section~\ref{sec:dns}) to publish instance
+names in the domain \code{\_presence.\_tcp.local}. For example, if Juliet uses
+her machine (named \code{capulet}) with serverless messaging, her client would
+publish the following four mDNS records:

 
 \begin{itemize}
   \item an A record \code{capulet.local}, specifying her IP address,
 
 \begin{itemize}
   \item an A record \code{capulet.local}, specifying her IP address,