sec-xmpp.tex

   1 \subsection{XMPP}
   2
   3 The \term{Extensible Messaging and Presence Protocol (XMPP)} is a distributed,
   4 XML-based protocol for real-time communication. Its core functionalities are
   5 specified in RFC~6120~\cite{rfc6120} and RFC~6122~\cite{rfc6121}, while protocol
   6 extensions are usually defined by the XMPP community in \term{XMPP Extension
   7 Proposals (XEPs)}.
   8
   9 \subsubsection{Addressing}
  10 \enlargethispage{2\baselineskip}
  11
  12 Every user account in XMPP is addressed by a globally unique identifier, called
  13 the \term{Jabber ID (JID)}~\cite{rfc6122}. It has the form
  14 \code{localpart@domain/resource}, where \code{domain} is the DNS name of an XMPP
  15 server, and \code{localpart} is the name of a user account on that server. Since
  16 a user can be logged in from multiple clients at the same time, the
  17 \code{resource} part is a string chosen by the user to distinguish those
  18 clients. Only the part \code{localpart@domain} (the \term{bare JID}) is
  19 needed to identify a user, the resource is only needed for routing between
  20 client and server.
  21
  22 \subsubsection{Architecture}
  23 \begin{wrapfigure}{r}{0.5\textwidth}
  24   \tikzstyle{iconlabel}=[text width=3cm, align=center, font=\footnotesize]
  25   \tikzstyle{label}=[font=\footnotesize]
  26   \begin{tikzpicture}[node distance=0pt,scale=1.5,>=stealth,thick]
  27     \def\nodelist{
  28       juliet/{(-1,-1)}/XMPP client \code{juliet@example.net}/below/computer,
  29       examplenet/{(-1,1)}/XMPP server \code{example.net}/above/server,
  30       imexampleorg/{(1,1)}/XMPP server \code{im.example.org}/above/server,
  31       romeo/{(1,-1)}/XMPP client \code{romeo@im.example.org}/below/computer%
  32     }
  33     \foreach \name/\pos/\text/\tpos/\icon in \nodelist {
  34       \node (\name) at \pos { \includegraphics[width=1cm]{icon-\icon.pdf} };
  35       \node[\tpos=of \name,iconlabel] (\name text) { \text };
  36     }
  37     \draw[<->,dashed] (juliet) -- node[anchor=east,label]{s2c} (examplenet);
  38     \draw[<->] (examplenet) -- node[anchor=south,label]{s2s} (imexampleorg);
  39     \draw[<->,dashed] (imexampleorg) -- node[anchor=west,label]{s2c} (romeo);
  40   \end{tikzpicture}
  41   \centering
  42   \caption{XMPP architecture, showing server-to-server (s2s) and
  43     server-to-client (s2c) connections}
  44   \label{fig:xmpparch}
  45 \end{wrapfigure}
  46
  47 The original architecture underlying XMPP strongly leans on the established
  48 design of Internet Mail, and an example is depicted in Fig.~\ref{fig:xmpparch}.
  49 The distributed network is formed by \term{XMPP servers} on one hand, which make
  50 up the always-on backbone of the network used for message routing, and which
  51 manage user accounts and statuses. On the other hand, \term{XMPP clients}
  52 represent a single logged-in user and make up the interface for communication
  53 with other users.
  54
  55 Every client communicates only with the server that manages the respective user
  56 account which is configured in the client, as given in the user's JID. The
  57 server then routes the messages to their recipients, using the JID to determine
  58 the correct server for a message to be sent to. Finally, the receiving server
  59 sends the message to a client where the receiving JID is logged in. If the user
  60 is not logged in at the time the message is sent, the server can store it for
  61 the user and deliver it on the next login.
  62
  63 XMPP strongly relies on DNS Service Discovery (see Section~\ref{sec:dnssd}) to
  64 determine the server being in charge of a domain. For example, the server who
  65 manages the users for the domain \code{example.org} is given by the SRV record
  66 \code{\_xmpp-server.\_tcp.example.org}.
  67
  68 \subsubsection{Communication primitives}
  69
  70 All communication over XMPP is based on XML. To minimize communication overhead,
  71 only fragments of XML, called \term{stanzas}, are sent between hosts. A stanza
  72 is always well-formed as a whole; it consists of a root element, which in most
  73 cases also includes routing attributes (\code{to} and \code{from}), and its
  74 optional child elements.
  75
  76 On top of that, living connections between hosts are represented by \term{XML
  77 streams}. The client initiates a connection by sending an XML declaration
  78 followed by an opening \code{<stream>} tag. The server then responds also with
  79 an opening \code{<stream>} tag. The client then performs SASL authentication and
  80 binds its stream to a resource for proper addressing. If this process succeeded,
  81 both client and server can send an unlimited number of stanzas, until the
  82 connection is closed by one side by sending a closing \code{</stream>} tag. The
  83 other side then has the chance to send all outstanding stanzas and then likewise
  84 closes its stream. If both streams are closed, the underlying TCP connection is
  85 terminated.
  86
  87 %\todo{see section... for example stream}
  88
  89 \subsubsection{Publish/Subscribe and Presence}
  90
  91 Typically, a user wants to chat with a more or less fixed set of other users,
  92 whose JIDs she needs to know, so she needs some kind of ``address book'' that
  93 remembers the JIDs for her. In XMPP, this address book is called
  94 \term{roster}, and it also shows the users' willingness to chat (``presence'').
  95 In order to see their chat status (which can be  one of ``online'', ``offline'',
  96 and several ``away'' or ``do not disturb'' states), a user needs to subscribe to
  97 the other user's status. The mechanism behind this is called
  98 \term{Publish-Subscribe} and is specified in XEP-0060~\cite{xep0060}. It can
  99 be used to notify interested users about changes in personal information, and
 100 implements the well-known Observer pattern.
 101
 102 A user publishes information by creating a \term{node} on the XMPP server, which
 103 acts as a handle for the data. Interested users can then query the server for
 104 nodes, and request subscription to them. When the owner of the node confirms the
 105 subscription request, subscribers get notified whenever the owner updates the
 106 respective node.
 107
 108 All communication takes place between the client and the server over \code{<iq>}
 109 (``information query'') stanzas.
 110
 111 \subsubsection{Multi-User Chats}
 112
 113 Besides one-to-one messaging, XMPP also allows users to create multi-user chat
 114 rooms, which is specified in XEP-0045~\cite{xep0045}. Each chat room is given a
 115 unique JID on the server managing the room to which the users send their
 116 messages to. Each incoming message is then dispatched to all users which have
 117 joined the room.
 118
 119 To join a room, the user sends a \code{<presence>} stanza to the room JID, where
 120 the resource part of the room JID specifies the desired nick name.
 121
 122 \subsubsection{XMPP Serverless Messaging}\label{sec:xsm}
 123
 124 To overcome the need for a central server and authentication, XMPP Serverless
 125 Messaging~\cite{xep0174} allows XMPP clients on a network to build a
 126 peer-to-peer mesh network and chat directly with each other. This feature was
 127 first introduced by Apple as part of their \term{Bonjour} project, and nowadays
 128 it is also available in many other XMPP clients.
 129
 130 %\begin{wrapfigure}{R}{0.4\textwidth}
 131   %\tikzstyle{iconlabel}=[text width=2cm, align=center, font=\footnotesize]
 132   %\tikzstyle{label}=[font=\footnotesize]
 133   %\begin{tikzpicture}[node distance=0pt,scale=1.2,>=stealth,thick]
 134     %\def\nodelist{
 135       %juliet/{(-1,-1)}/\code{juliet@\ balcony.local}/below/computer,
 136       %tybalt/{(-1,1)}/\code{tybalt@\ montague.local}/above/computer,
 137       %mercutio/{(1,1)}/\code{mercutio@\ capulet.local}/above/computer,
 138       %romeo/{(1,-1)}/\code{romeo@\ romeo.local}/below/computer%
 139     %}
 140     %\foreach \name/\pos/\text/\tpos/\icon in \nodelist {
 141       %\node (\name) at \pos { \includegraphics[width=1cm]{icon-\icon.pdf} };
 142       %\node[\tpos=of \name,iconlabel] (\name text) { \text };
 143     %}
 144     %\draw[<->,dashed] (juliet) -- (tybalt);
 145     %\draw[<->,dashed] (juliet) -- (romeo);
 146     %\draw[<->,dashed] (juliet) -- (mercutio);
 147     %\draw[<->,dashed] (romeo) -- (mercutio);
 148     %\draw[<->,dashed] (romeo) -- (tybalt);
 149     %\draw[<->,dashed] (mercutio) -- (tybalt);
 150   %\end{tikzpicture}
 151   %\centering
 152   %\caption{XMPP architecture with Serverless Messaging}
 153   %\label{fig:xmpparch2}
 154 %\end{wrapfigure}
 155
 156 With XMPP Serverless Messaging, XMPP clients simply open a port on their host,
 157 and then rely on mDNS and DNS-SD (see Section~\ref{sec:dns}) to publish instance
 158 names in the domain \code{\_presence.\_tcp.local}. For example, if Juliet uses
 159 her machine (named \code{capulet}) with serverless messaging, her client would
 160 publish the following four mDNS records:
 161
 162 \begin{itemize}
 163   \item an A record \code{capulet.local}, specifying her IP address,
 164   \item an SRV record \code{juliet@capulet.\_presence.\_tcp.local}, specifying
 165     the port on which her XMPP client listens, and refering to
 166     \code{capulet.local} as the host name
 167   \item a PTR record \code{\_presence.\_tcp.local} for service discovery,
 168     pointing to \code{juliet@capulet.\_presence.\_tcp.local}
 169   \item and a TXT record \code{juliet@capulet.\_presence.\_tcp.local} specifying
 170     more information about her (e.~g. her online status, contact data, etc.) in
 171     standardized key-value pairs.
 172 \end{itemize}
 173
 174 When other clients in the same network enumerate the available services by
 175 querying \code{\_presence.\_tcp.local}, they notice Juliet's presence and add
 176 her to the roster automatically. In that way, XMPP users can see who is
 177 currently available for communication. To start a chat session, clients initiate
 178 a TCP connection over the advertised ports, open their XML streams, and send
 179 message or IQ stanzas like they would to an XMPP server. Presence is managed
 180 over the corresponding TXT record in the mDNS. To go offline, a client
 181 announces the deletion of its mDNS records.
 182
 183 % vim: set ft=tex et ts=2 sw=2 :