From: Roland Hieber Date: Sat, 14 Dec 2013 01:02:55 +0000 (+0100) Subject: rename files X-Git-Tag: erste-version~4 X-Git-Url: https://git.rohieb.name/skm-ma-ws1314.git/commitdiff_plain/a1c81dce7c7d4e3a0e6e1f446eaeb893845fd680 rename files --- diff --git a/address-allocation.tex b/address-allocation.tex deleted file mode 100644 index 4198074..0000000 --- a/address-allocation.tex +++ /dev/null @@ -1,73 +0,0 @@ -\subsection{Address allocation} -Considering the TCP/IP protocol suite, in order to be able to communicate on the -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. There are several ways of achieving this: - -\begin{itemize} - \item The IP address is pre-selected by a human and stored in the device - configuration. This process is cumbersome when more than one device needs to - be configured, and humans have to remember which addresses are configured on - which device, and which addresses are still free to use on additional - devices. - - \item Deploying a central server that assigns network addresses - to the devices in the network, which in order query the server (for example - via broadcast or on a lower layer) for a unique address before they use the - IP layer for the first time. This technique supersedes the dependency of - human memory for mapping IP addresses to devices, and can easily be combined - with additional central configuration management, like the automatic - assignment of a static gateway, or a DNS resolver.\\ - The DHCP protocol is one example of central IP address management. - - \item A third alternative is the use of a distributed protocol which enables - the devices on the network to choose addresses in accordance with other - devices on the same network, so no IP address is used more than once. In - respect to the Internet of Things, this approach has the advantage that - those devices can easily be used in different scenarios without needing - central deployment at all, and also allowing them to change their addresses - dynamically, therefore easily reacting to changes in the network. \\ - There are two major protocols which are used for dynamic configuration of IP - addresses. In the IPv4 world, Link-Local Addressing~\cite{rfc3927} is often - used, and in IPv6 networks, Stateless Address - Autoconfiguration~\cite{rfc4862} is a fundamental feature built into every - device. - -\end{itemize} - -\paragraph{IPv4 Link-Local Addressing} - -\term{Link-Local Addressing}, also known as \term{Automatic Private IP -Addressing (APIPA)} or \term{Zeroconf}, uses the IPv4 subnet -\code{169.254.0.0/16} for addressing. Every device first chooses a random -address from that address space. Then it checks if the chosen address is used -by any other device on the network by probing the chosen address, which is -usually done using the ARP protocol. If the probing process results that the -address is not used on the network (e.~g. no device returned an ARP response -during a random time interval), the device claims its chosen address and uses it -for communication on the IPv4 layer. If the chosen address is already used, the - device continues the process, subsequently choosing a new random address and - trying to claim it, until a free address has been found. - -\paragraph{IPv6 Stateless Address Autoconfiguration} - -Similar to IPv4 Link-Local Addressing, devices configured with \term{IPv6 -Stateless Addressing Autoconfiguration} use an IPv6 address from the subnet -\code{fe80::/64}. First, an \term{interface identifier} is generated using the -interface's MAC address. Since MAC addresses must be unique in the network, a -unique IPv6 address is obtained by combining the subnet prefix and the interface -identifier. To ensure that no other device exists with this generated IPv6 -address, the device performs \term{Duplicate Address Detection} on the network -through \term{Neighbor Advertisement} messages and listening for \term{Neighbor -Solicitation} messages. If such messages are received from other hosts, the -configured address cannot be used by the device and must be discarded. -Therefore, in order to use IPv6 effectively, it must be guarranteed that MAC -addresses are unique on the network. - -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 -which contain a global network prefix. The hosts on the network can then use -that prefix instead to configure a global IPv6 address. - -% vim: set ft=tex et ts=2 sw=2 : diff --git a/dns-extensions.tex b/dns-extensions.tex deleted file mode 100644 index c4c84e3..0000000 --- a/dns-extensions.tex +++ /dev/null @@ -1,82 +0,0 @@ -\subsection{Extensions to the Domain Name System}\label{sec:dns} - -In a distributed context, it is often not feasible to rely on a central, -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. - -\subsubsection{Multicast DNS} - -\term{Multicast DNS}~\cite{rfc6762} (mDNS) 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 -named \code{.local}, is used. - -Software that supports mDNS listens on the reserved -link-local multicast address \code{224.0.0.251} (for IPv4 queries) or -\code{FF02::FB} (for IPv6 queries) on UDP port 5353 for incoming queries. -Queries sent to those multicast address and port are standard DNS queries. -If a host receives a query and knows about the queried resource, it responds to the -querying host with a standard DNS response. The querying host can then simply -finish and use the result, or wait until other hosts respond to its query. The -latter is typically the case when a record can have multiple values, as it is -the case with \code{SRV} and \code{PTR} records. - -Another feature of Multicast DNS is the reduction of traffic through -\term{Known-Answer Suppression}. It allows a querying host to specify already -known resources in its query when querying resources that could exist on more -than one host (e.~g., SRV records). The hosts matching those resources then do -not generate a response. - -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}. - -\begin{figure}[top] - \centering - \includegraphics[width=0.9\textwidth]{dnssd-mock.jpg} - \caption{DNS-SD: Service Instance Enumeration and Resolution - \todo[XMPP is a bad example here, use IPP]} - \label{fig:dnssd} -\end{figure} - -\paragraph{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. - -\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 -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 -supported paper sizes). - -Through the usage of \code{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}. - -\pages{1} -% vim: set ft=tex et ts=2 sw=2 : diff --git a/dnssd-mock.jpg b/dnssd-mock.jpg deleted file mode 100644 index 9d90ecb..0000000 Binary files a/dnssd-mock.jpg and /dev/null differ diff --git a/fig-dnssd-mock.jpg b/fig-dnssd-mock.jpg new file mode 100644 index 0000000..9d90ecb Binary files /dev/null and b/fig-dnssd-mock.jpg differ diff --git a/fig-xmpp-architecture-mock.jpg b/fig-xmpp-architecture-mock.jpg new file mode 100644 index 0000000..dcaaec1 Binary files /dev/null and b/fig-xmpp-architecture-mock.jpg differ diff --git a/main.tex b/main.tex index 8219bb3..bd1cb9b 100644 --- a/main.tex +++ b/main.tex @@ -38,9 +38,9 @@ overview to the techniques used in the paper by Klauk and Kirsche \cite{klauck-kirsche-chattythings} -\input{address-allocation.tex} -\input{dns-extensions.tex} -\input{xmpp.tex} +\input{sec-address-allocation.tex} +\input{sec-dns-extensions.tex} +\input{sec-xmpp.tex} \input{sec-chatty-things.tex} \section{Related Approaches} diff --git a/sec-address-allocation.tex b/sec-address-allocation.tex new file mode 100644 index 0000000..4198074 --- /dev/null +++ b/sec-address-allocation.tex @@ -0,0 +1,73 @@ +\subsection{Address allocation} +Considering the TCP/IP protocol suite, in order to be able to communicate on the +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. There are several ways of achieving this: + +\begin{itemize} + \item The IP address is pre-selected by a human and stored in the device + configuration. This process is cumbersome when more than one device needs to + be configured, and humans have to remember which addresses are configured on + which device, and which addresses are still free to use on additional + devices. + + \item Deploying a central server that assigns network addresses + to the devices in the network, which in order query the server (for example + via broadcast or on a lower layer) for a unique address before they use the + IP layer for the first time. This technique supersedes the dependency of + human memory for mapping IP addresses to devices, and can easily be combined + with additional central configuration management, like the automatic + assignment of a static gateway, or a DNS resolver.\\ + The DHCP protocol is one example of central IP address management. + + \item A third alternative is the use of a distributed protocol which enables + the devices on the network to choose addresses in accordance with other + devices on the same network, so no IP address is used more than once. In + respect to the Internet of Things, this approach has the advantage that + those devices can easily be used in different scenarios without needing + central deployment at all, and also allowing them to change their addresses + dynamically, therefore easily reacting to changes in the network. \\ + There are two major protocols which are used for dynamic configuration of IP + addresses. In the IPv4 world, Link-Local Addressing~\cite{rfc3927} is often + used, and in IPv6 networks, Stateless Address + Autoconfiguration~\cite{rfc4862} is a fundamental feature built into every + device. + +\end{itemize} + +\paragraph{IPv4 Link-Local Addressing} + +\term{Link-Local Addressing}, also known as \term{Automatic Private IP +Addressing (APIPA)} or \term{Zeroconf}, uses the IPv4 subnet +\code{169.254.0.0/16} for addressing. Every device first chooses a random +address from that address space. Then it checks if the chosen address is used +by any other device on the network by probing the chosen address, which is +usually done using the ARP protocol. If the probing process results that the +address is not used on the network (e.~g. no device returned an ARP response +during a random time interval), the device claims its chosen address and uses it +for communication on the IPv4 layer. If the chosen address is already used, the + device continues the process, subsequently choosing a new random address and + trying to claim it, until a free address has been found. + +\paragraph{IPv6 Stateless Address Autoconfiguration} + +Similar to IPv4 Link-Local Addressing, devices configured with \term{IPv6 +Stateless Addressing Autoconfiguration} use an IPv6 address from the subnet +\code{fe80::/64}. First, an \term{interface identifier} is generated using the +interface's MAC address. Since MAC addresses must be unique in the network, a +unique IPv6 address is obtained by combining the subnet prefix and the interface +identifier. To ensure that no other device exists with this generated IPv6 +address, the device performs \term{Duplicate Address Detection} on the network +through \term{Neighbor Advertisement} messages and listening for \term{Neighbor +Solicitation} messages. If such messages are received from other hosts, the +configured address cannot be used by the device and must be discarded. +Therefore, in order to use IPv6 effectively, it must be guarranteed that MAC +addresses are unique on the network. + +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 +which contain a global network prefix. The hosts on the network can then use +that prefix instead to configure a global IPv6 address. + +% vim: set ft=tex et ts=2 sw=2 : diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex new file mode 100644 index 0000000..5be64d4 --- /dev/null +++ b/sec-chatty-things.tex @@ -0,0 +1,7 @@ +\section{System Architecture of ``Chatty Things''} +\todo +\pages{3} +\subsection{Service Provisioning Sublayer} +\subsection{Bootstrapping} +\subsection{Presence Subscription} + diff --git a/sec-dns-extensions.tex b/sec-dns-extensions.tex new file mode 100644 index 0000000..7ef413c --- /dev/null +++ b/sec-dns-extensions.tex @@ -0,0 +1,82 @@ +\subsection{Extensions to the Domain Name System}\label{sec:dns} + +In a distributed context, it is often not feasible to rely on a central, +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. + +\subsubsection{Multicast DNS} + +\term{Multicast DNS}~\cite{rfc6762} (mDNS) 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 +named \code{.local}, is used. + +Software that supports mDNS listens on the reserved +link-local multicast address \code{224.0.0.251} (for IPv4 queries) or +\code{FF02::FB} (for IPv6 queries) on UDP port 5353 for incoming queries. +Queries sent to those multicast address and port are standard DNS queries. +If a host receives a query and knows about the queried resource, it responds to the +querying host with a standard DNS response. The querying host can then simply +finish and use the result, or wait until other hosts respond to its query. The +latter is typically the case when a record can have multiple values, as it is +the case with \code{SRV} and \code{PTR} records. + +Another feature of Multicast DNS is the reduction of traffic through +\term{Known-Answer Suppression}. It allows a querying host to specify already +known resources in its query when querying resources that could exist on more +than one host (e.~g., SRV records). The hosts matching those resources then do +not generate a response. + +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}. + +\begin{figure}[top] + \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]} + \label{fig:dnssd} +\end{figure} + +\paragraph{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. + +\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 +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 +supported paper sizes). + +Through the usage of \code{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}. + +\pages{1} +% vim: set ft=tex et ts=2 sw=2 : diff --git a/sec-xmpp.tex b/sec-xmpp.tex new file mode 100644 index 0000000..451a317 --- /dev/null +++ b/sec-xmpp.tex @@ -0,0 +1,121 @@ +\subsection{XMPP} +\todo +\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 +extensions are usually defined by the XMPP community in \term{XMPP Extension +Proposals (XEPs)}. + +\subsubsection{Addressing} + +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. + +\subsubsection{Architecture} +\begin{wrapfigure}{r}{0.4\textwidth} +%\begin{figure}[htop] + \centering + \includegraphics[width=0.4\textwidth]{fig-xmpp-architecture-mock.jpg} + \caption{XMPP architecture} + \label{fig:xmpparch} +%\end{figure} +\end{wrapfigure} + +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 routing message, and manage +user accounts and statuses. On the other hand, \term{XMPP clients} represent a +single logged-in user and are 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 +server then routes the messages to their recipients, using the JID to determine +the correct server for a message to be sent to. Finally, the receiving server +sends the message to a client where the receiving JID is logged in. If the user +is not logged in at the time the message is sent, the server can store it for +the user and deliver it on the next login. + +XMPP strongly relies on DNS Service Discovery (see Section~\ref{sec:dnssd}) to +determine the server being in charge of a domain. For example, the server who +manages the users for the domain \code{example.org} is given by the SRV record +\code{\_xmpp-server.\_tcp.example.org}. + +\subsubsection{Communication primitives} + +All communication over XMPP is based on XML. To minimize communication overhead, +only fragments of XML, called \term{stanzas}, are sent between hosts. A stanza +is always well-formed as a whole; it consist of a root element, which also +includes routing attributes (\code{to} and \code{from}), and its optional child +elements. + +On top of that, living connections between hosts are represented by \term{XML +streams}. The client initiates a connection by sending an XML declaration +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 +other side then has the chance to send all outstanding stanzas and likewise +closes its stream. If both streams are closed, the underlying TCP connection is +terminated. + +\todo[Example stream] + +\subsubsection{Multi-User Chats} + +\cite{xep-0045} + +\subsubsection{Publish/Subscribe, Presence and the Roster} + +\cite{xep-0060} + + +\cite{rfc6121} + +\subsubsection{XMPP Serverless Messaging} +\todo + +To overcome the need for a central server and authentication, XMPP Serverless +Messaging~\cite{xep-0174} 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} 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: + +\begin{itemize} + \item an A record \code{capulet.local}, specifying her IP address, + \item an SRV record \code{juliet@capulet.\_presence.\_tcp.local}, specifying + the port on which her XMPP client listens, and refering to + \code{capulet.local} as the host name + \item a PTR record \code{\_presence.\_tcp.local} for service discovery, + pointing to \code{juliet@capulet.\_presence.\_tcp.local} + \item and a TXT record \code{juliet@capulet.\_presence.\_tcp.local} specifying + more information about her (e.~g. her online status, contact data, etc.) +\end{itemize} + +When other clients in the same network enumerate the available services by +querying \code{\_presence.\_tcp.local}, they notice Juliet's presence and add +her to the roster automatically. In that way, XMPP users can see who is +currently available for communication. To start a chat session, clients initiate +a TCP connection over the advertised ports, open their XML streams, and send +message or IQ stanzas like they would to an XMPP server. Presence is managed +over the corresponding TXT record in the mDNS. To go offline, a client +announces the deletion of its mDNS records. + +\pages{1} + +% vim: set ft=tex et ts=2 sw=2 : diff --git a/xmpp-architecture-mock.jpg b/xmpp-architecture-mock.jpg deleted file mode 100644 index dcaaec1..0000000 Binary files a/xmpp-architecture-mock.jpg and /dev/null differ diff --git a/xmpp.tex b/xmpp.tex deleted file mode 100644 index 7bef910..0000000 --- a/xmpp.tex +++ /dev/null @@ -1,121 +0,0 @@ -\subsection{XMPP} -\todo -\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 -extensions are usually defined by the XMPP community in \term{XMPP Extension -Proposals (XEPs)}. - -\subsubsection{Addressing} - -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. - -\subsubsection{Architecture} -\begin{wrapfigure}{r}{0.4\textwidth} -%\begin{figure}[htop] - \centering - \includegraphics[width=0.4\textwidth]{xmpp-architecture-mock.jpg} - \caption{XMPP architecture} - \label{fig:xmpparch} -%\end{figure} -\end{wrapfigure} - -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 routing message, and manage -user accounts and statuses. On the other hand, \term{XMPP clients} represent a -single logged-in user and are 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 -server then routes the messages to their recipients, using the JID to determine -the correct server for a message to be sent to. Finally, the receiving server -sends the message to a client where the receiving JID is logged in. If the user -is not logged in at the time the message is sent, the server can store it for -the user and deliver it on the next login. - -XMPP strongly relies on DNS Service Discovery (see Section~\ref{sec:dnssd}) to -determine the server being in charge of a domain. For example, the server who -manages the users for the domain \code{example.org} is given by the SRV record -\code{\_xmpp-server.\_tcp.example.org}. - -\subsubsection{Communication primitives} - -All communication over XMPP is based on XML. To minimize communication overhead, -only fragments of XML, called \term{stanzas}, are sent between hosts. A stanza -is always well-formed as a whole; it consist of a root element, which also -includes routing attributes (\code{to} and \code{from}), and its optional child -elements. - -On top of that, living connections between hosts are represented by \term{XML -streams}. The client initiates a connection by sending an XML declaration -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 -other side then has the chance to send all outstanding stanzas and likewise -closes its stream. If both streams are closed, the underlying TCP connection is -terminated. - -\todo[Example stream] - -\subsubsection{Multi-User Chats} - -\cite{xep-0045} - -\subsubsection{Publish/Subscribe, Presence and the Roster} - -\cite{xep-0060} - - -\cite{rfc6121} - -\subsubsection{XMPP Serverless Messaging} -\todo - -To overcome the need for a central server and authentication, XMPP Serverless -Messaging~\cite{xep-0174} 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} 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: - -\begin{itemize} - \item an A record \code{capulet.local}, specifying her IP address, - \item an SRV record \code{juliet@capulet.\_presence.\_tcp.local}, specifying - the port on which her XMPP client listens, and refering to - \code{capulet.local} as the host name - \item a PTR record \code{\_presence.\_tcp.local} for service discovery, - pointing to \code{juliet@capulet.\_presence.\_tcp.local} - \item and a TXT record \code{juliet@capulet.\_presence.\_tcp.local} specifying - more information about her (e.~g. her online status, contact data, etc.) -\end{itemize} - -When other clients in the same network enumerate the available services by -querying \code{\_presence.\_tcp.local}, they notice Juliet's presence and add -her to the roster automatically. In that way, XMPP users can see who is -currently available for communication. To start a chat session, clients initiate -a TCP connection over the advertised ports, open their XML streams, and send -message or IQ stanzas like they would to an XMPP server. Presence is managed -over the corresponding TXT record in the mDNS. To go offline, a client -announces the deletion of its mDNS records. - -\pages{1} - -% vim: set ft=tex et ts=2 sw=2 :