sync: chatty things: service provisioning, bootstrap
[skm-ma-ws1314.git] / sec-xmpp.tex
1 \subsection{XMPP}
2 \todo
3 \pages{3-4}
5 The \term{Extensible Messaging and Presence Protocol (XMPP)} is a distributed,
6 XML-based protocol for real-time communication. Its core functionalities are
7 specified in RFCs~6120~\cite{rfc6120} and RFC~6122~\cite{rfc6121}, while protocol
8 extensions are usually defined by the XMPP community in \term{XMPP Extension
9 Proposals (XEPs)}.
11 \subsubsection{Addressing}
13 Every user account in XMPP is addressed by a globally unique identifier, called
14 the \term{Jabber ID (JID)}~\cite{rfc6122}. It has the form
15 \code{localpart@domainpart/resource}, where \code{domainpart} is the DNS name of
16 an XMPP server, and \code{localpart} is the name of a user account on that
17 server. Since a user can be logged in from multiple clients, the \code{resource}
18 part is a string chosen by the user to distinguish those clients. Only the part
19 \code{localpart@domainpart} (the \term{bare JID}) is needed to identify a user,
20 the resource is only needed for routing between client and server.
22 \subsubsection{Architecture}
23 \begin{wrapfigure}{r}{0.4\textwidth}
24 %\begin{figure}[htop]
25 \centering
26 \includegraphics[width=0.4\textwidth]{fig-xmpp-architecture-mock.jpg}
27 \caption{XMPP architecture}
28 \label{fig:xmpparch}
29 %\end{figure}
30 \end{wrapfigure}
32 The original architecture underlying XMPP strongly leans on the established
33 design of Internet Mail, and an example is depicted in Fig.~\ref{fig:xmpparch}.
34 The distributed network is formed by \term{XMPP servers} on one hand, which make
35 up the always-on backbone of the network used for routing message, and manage
36 user accounts and statuses. On the other hand, \term{XMPP clients} represent a
37 single logged-in user and are the interface for communication with other users.
39 Every client communicates only with the server that manages the respective user
40 account which is configured in the client, as given in the user's JID. The
41 server then routes the messages to their recipients, using the JID to determine
42 the correct server for a message to be sent to. Finally, the receiving server
43 sends the message to a client where the receiving JID is logged in. If the user
44 is not logged in at the time the message is sent, the server can store it for
45 the user and deliver it on the next login.
47 XMPP strongly relies on DNS Service Discovery (see Section~\ref{sec:dnssd}) to
48 determine the server being in charge of a domain. For example, the server who
49 manages the users for the domain \code{} is given by the SRV record
50 \code{\_xmpp-server.\}.
52 \subsubsection{Communication primitives}
54 All communication over XMPP is based on XML. To minimize communication overhead,
55 only fragments of XML, called \term{stanzas}, are sent between hosts. A stanza
56 is always well-formed as a whole; it consist of a root element, which also
57 includes routing attributes (\code{to} and \code{from}), and its optional child
58 elements.
60 On top of that, living connections between hosts are represented by \term{XML
61 streams}. The client initiates a connection by sending an XML declaration
62 followed by an opening \code{<stream>} tag. The server then responds also with
63 an opening \code{<stream>} tag. The client then performs SASL authentication and
64 binds its stream to a resource for proper addressing. If this process succeeded,
65 both client and server can send an unlimited number of stanzas, until the
66 connection is closed by one side by sending an closing \code{</stream>} tag. The
67 other side then has the chance to send all outstanding stanzas and likewise
68 closes its stream. If both streams are closed, the underlying TCP connection is
69 terminated.
71 \todo[Example stream]
73 \subsubsection{Multi-User Chats}
75 \cite{xep-0045}
77 \subsubsection{Publish/Subscribe, Presence and the Roster}
79 \cite{xep-0060}
82 \cite{rfc6121}
84 \subsubsection{XMPP Serverless Messaging}\label{sec:xsm}
85 \todo
87 To overcome the need for a central server and authentication, XMPP Serverless
88 Messaging~\cite{xep-0174} allows XMPP clients on a network to build a
89 peer-to-peer mesh network and chat directly with each other. This feature was
90 first introduced by Apple as part of their \term{Bonjour} project, and nowadays
91 it is also available in many other XMPP clients.
93 With XMPP Serverless Messaging, XMPP clients simply open a port on the host, and
94 then rely on mDNS and DNS-SD (see Section~\ref{sec:dns})
95 to publish instance names in the domain \code{\_presence.\_tcp.local}. For
96 example, if Juliet uses her machine (named \code{capulet}) with serverless
97 messaging, her client would publish the following four mDNS records:
99 \begin{itemize}
100 \item an A record \code{capulet.local}, specifying her IP address,
101 \item an SRV record \code{juliet@capulet.\_presence.\_tcp.local}, specifying
102 the port on which her XMPP client listens, and refering to
103 \code{capulet.local} as the host name
104 \item a PTR record \code{\_presence.\_tcp.local} for service discovery,
105 pointing to \code{juliet@capulet.\_presence.\_tcp.local}
106 \item and a TXT record \code{juliet@capulet.\_presence.\_tcp.local} specifying
107 more information about her (e.~g. her online status, contact data, etc.)
108 \end{itemize}
110 When other clients in the same network enumerate the available services by
111 querying \code{\_presence.\_tcp.local}, they notice Juliet's presence and add
112 her to the roster automatically. In that way, XMPP users can see who is
113 currently available for communication. To start a chat session, clients initiate
114 a TCP connection over the advertised ports, open their XML streams, and send
115 message or IQ stanzas like they would to an XMPP server. Presence is managed
116 over the corresponding TXT record in the mDNS. To go offline, a client
117 announces the deletion of its mDNS records.
119 \pages{1}
121 % vim: set ft=tex et ts=2 sw=2 :
This page took 0.060709 seconds and 5 git commands to generate.