From 9c0186068ed8d750cbae9dae7740f312a7663fe8 Mon Sep 17 00:00:00 2001 From: Roland Hieber Date: Mon, 23 Dec 2013 22:54:06 +0100 Subject: [PATCH] polishing --- main.tex | 1 - sec-address-allocation.tex | 27 +++++++------ sec-chatty-things.tex | 28 +++++++------ sec-discussion.tex | 70 ++++++++++++++++----------------- sec-dns-extensions.tex | 63 +++++++++++++----------------- sec-intro.tex | 2 - sec-xmpp.tex | 80 +++++++++++++++++++++++++------------- 7 files changed, 143 insertions(+), 128 deletions(-) diff --git a/main.tex b/main.tex index d187088..cd97214 100644 --- a/main.tex +++ b/main.tex @@ -28,7 +28,6 @@ Masses with XMPP} \maketitle \input{sec-intro.tex} - %% Prerequisites \section{Prerequisites}\label{sec:prereq} diff --git a/sec-address-allocation.tex b/sec-address-allocation.tex index d2d0625..ba09a10 100644 --- 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 -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 -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 -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 @@ -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. -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 -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 -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. diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex index 13407c0..da27fbe 100644 --- 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. -\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. -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 @@ -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: -\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 - 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} @@ -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 -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 -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 @@ -93,14 +91,16 @@ over XMPP Serverless Messaging. 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 - \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} -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 @@ -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} -\todo{short conclusion?} - \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 -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 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{} 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{} 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{} 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{} or \code{} 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 : diff --git a/sec-dns-extensions.tex b/sec-dns-extensions.tex index d3ec16e..dae9770 100644 --- 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 -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} -\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 @@ -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. +\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. -\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 -\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 -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. -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). -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 -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 : diff --git a/sec-intro.tex b/sec-intro.tex index 6a385d9..b93bd66 100644 --- a/sec-intro.tex +++ b/sec-intro.tex @@ -1,7 +1,5 @@ %% 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 diff --git a/sec-xmpp.tex b/sec-xmpp.tex index 41a9ca4..9f1749a 100644 --- a/sec-xmpp.tex +++ b/sec-xmpp.tex @@ -1,22 +1,23 @@ \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 -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} +\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 -\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} @@ -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 -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 @@ -78,16 +79,18 @@ followed by an opening \code{} tag. The server then responds also with an opening \code{} 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{} tag. The +connection is closed by one side by sending a closing \code{} 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. +%\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 -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 @@ -109,27 +112,52 @@ All communication takes place between the client and the server over \code{} 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{} 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 -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, -- 2.20.1