sec-xmpp.tex

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